It takes a while to process a lot of data
http://archives.postgresql.org/message-id/4E948263.8040305@consistentstate.com
http://archives.postgresql.org/message-id/4EB1A419.1080901@consistentstate.com (small row counts, but basically the same issue)
http://archives.postgresql.org/message-id/4EB1A63E.80101@consistentstate.com
Disks are slower than memory
http://archives.postgresql.org/message-id/4EAC10D4.1080300@comodo.com
http://archives.postgresql.org/message-id/1334333687863-5638777.post@n5.nabble.com
http://www.postgresql.org/message-id/001501ce1054$7b518380$71f48a80$@sympatico.ca
Clauses involving multiple tables can't be pushed down
http://archives.postgresql.org/message-id/3479994c.402ea88e.4e3797ac.972cd@tlen.pl [concatenation across values from different tables prevents pushdown; OR prevents pushdown]
Random I/O is slower than sequential I/O
Linearly scanning an array is O(n)
http://archives.postgresql.org/message-id/4EE75936.8040806@ruptela.lt
Can't figure out which patterns match a string without trying them all
http://archives.postgresql.org/message-id/4EE9533E.1050001@gmail.com
One regular expression is faster than two
Scanning more tables is slower than scanning fewer tables
Replanning isn't free
http://www.postgresql.org/message-id/035b01ce20e9$38ec92a0$aac5b7e0$@ang.com.pl
xmlconcat is slow, especially when iterated
http://www.postgresql.org/message-id/512738B3.4070309@esitelsrl.it
xmlagg is much slower than string_agg
http://archives.postgresql.org/message-id/4DFF0CD9.9010805@nsoft.lt
UNION is slower than UNION ALL
http://www.postgresql.org/message-id/20130227100352.GA46292@nataraj.karasik.eu.org