Re: [HACKERS] How to read query plan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] How to read query plan
Дата
Msg-id 4850.1110776411@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: How to read query plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] How to read query plan  (Miroslav Šulc <miroslav.sulc@startnet.cz>)
Список pgsql-performance
I wrote:
> Since ExecProject operations within a nest of joins are going to be
> dealing entirely with Vars, I wonder if we couldn't speed matters up
> by having a short-circuit case for a projection that is only Vars.
> Essentially it would be a lot like execJunk.c, except able to cope
> with two input tuples.  Using heap_deformtuple instead of retail
> extraction of fields would eliminate the O(N^2) penalty for wide tuples.

Actually, we already had a pending patch (from Atsushi Ogawa) that
eliminates that particular O(N^2) behavior in another way.  After
applying it, I get about a factor-of-4 reduction in the runtime for
Miroslav's example.

ExecEvalVar and associated routines are still a pretty good fraction of
the runtime, so it might still be worth doing something like the above,
but it'd probably be just a marginal win instead of a big win.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Postgres on RAID5
Следующее
От: Tom Lane
Дата:
Сообщение: Re: cpu_tuple_cost