NOT IN is hard to optimize
http://archives.postgresql.org/message-id/16161.1324414006@sss.pgh.pa.us
http://archives.postgresql.org/message-id/12106.1325009566@sss.pgh.pa.us
cross-data-type comparisons are not always indexable
http://archives.postgresql.org/message-id/DF644560-967D-4B1B-BEE0-49020DC1359F@inf.unibz.it
target lists are computed too early or unnecessarily
http://archives.postgresql.org/message-id/CAK-MWwTasteHbxcSN69jKfBbXJmxxUrtH7xL-jaBjEj3_2xfaQ@mail.gmail.com [before ORDER BY/LIMIT]
http://www.postgresql.org/message-id/20130414123414.00000718@unknown [before ORDER BY/LIMIT]
http://www.postgresql.org/message-id/51304B61.5030103@gmail.com [appendrel]
inlining can lose if we inline the same thing multiple times
http://archives.postgresql.org/message-id/E1RfAwz-0006Us-7B@wrigleys.postgresql.org
http://archives.postgresql.org/message-id/0238E40E527049828C48675488422F6D@CAPRICA
http://archives.postgresql.org/message-id/16161.1324414006@sss.pgh.pa.us [a query with many nodes can use too many copies of work_mem]
The query planner does not deduce implied inequalities.
See http://archives.postgresql.org/message-id/676.1308068945@sss.pgh.pa.us
It won't propagate IN or other criteria either: e.g. a IN (...) and a = b does not imply b IN (...)
http://archives.postgresql.org/message-id/alpine.LNX.2.01.1202261358070.31287@stax.localdomain
http://www.postgresql.org/message-id/25076.1366321335@sss.pgh.pa.us
Can't rewrite SELECT max(blah) WHERE dork IN (...) as max of index scans
http://archives.postgresql.org/message-id/BANLkTimsNMhnAHk6Wz7gARfdkTmz2QKJ7g@mail.gmail.com
http://archives.postgresql.org/message-id/4E8AD46F.30003@thl.fi
Query planner isn't smart about rearranging aggregates and joins
http://archives.postgresql.org/message-id/alpine.LNX.2.01.1202261358070.31287@stax.localdomain
WHERE a OR b not equivalent to WHERE a UNION WHERE b
Can't implement partitioned join as UNION of joins (and then push GROUP BY through it!)
Planner doesn't translate between IN (...) and =ANY(ARRAY((subquery))
GIN can't decide to index some AND-ed quals but not others
http://archives.postgresql.org/message-id/2f73f1348320af71b0551e2934d588ca.squirrel@shrek.krogh.cc
Range operators can't use btree indexes on base types
http://www.postgresql.org/message-id/514A5088.6060101@agliodbs.com
STRICT functions are hard to inline
http://archives.postgresql.org/message-id/4EB9BB3F.6090504@agliodbs.com
Only unqualified baserels can be pulled up into an appendrel
http://archives.postgresql.org/message-id/4F529E85.8010506@informatik.uni-leipzig.de
Planner converts IN clauses to semijoins before constant simplification
http://www.postgresql.org/message-id/2374.1366296417@sss.pgh.pa.us
Query planner doesn't discard unnecessary sorts
http://archives.postgresql.org/message-id/4F4F6158.7060200@mejor.pl
Parameterized queries defeat constraint exclusion
http://archives.postgresql.org/message-id/zarafa.4edf8328.2dfa.0b8fae0b2af83bae@meel.technocon.local