Markus Schaber <[EMAIL PROTECTED]> writes: > IMHO, this tells the reason. The query planner has a table size of 3 > pages, which clearly is a case for a seqscan. But during the seqscan, > the database has to fetch an additional amount of 8225 toast pages and > 127 toast index pages, and rebuild the geometries contained therein.
I don't buy this analysis at all. The toasted columns are not those in the index (because we don't support out-of-line-toasted index entries), so a WHERE clause that only touches indexed columns isn't going to need to fetch anything from the toast table. The only stuff it would fetch is in rows that passed the WHERE and need to be returned to the client --- and those costs are going to be the same either way. I'm not entirely sure where the time is going, but I do not think you have proven your theory about it. I'd suggest building the backend with -pg and getting some gprof evidence. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster