Re: Bad query optimizer misestimation because of TOAST tables

Markus Schaber <schabios(at)logi-track(dot)com> 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