Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Mittwoch, 9. Mai 2007 19:40 schrieb Tom Lane: >> Hmmm ... I see at least part of the problem, which is that email_header >> is joined twice in this query, which means that it's counted twice in >> figuring the total volume of pages competing for cache space. So the >> thing thinks cache space is oversubscribed nearly 3X when in reality >> the database is fully cached.
> I should add that other, similar queries in this database that do not > involve joining the same table twice produce seemingly optimal plans. > (It picks hash joins which are actually faster than nested loops.) It strikes me that in a situation like this, where the same table is being scanned twice by concurrent indexscans, we ought to amortize the fetches across *both* scans rather than treating them independently; so there are actually two different ways in which we're being too pessimistic about the indexscanning cost. Difficult to see how to fix that in the current planner design however; since it's a bottom-up process, we have to cost the individual scans without any knowledge of what approach will be chosen for other scans. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org