Re: [HACKERS] WIP: Faster Expression Processing v4

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] WIP: Faster Expression Processing v4
Дата
Msg-id 4542.1489608434@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-03-15 15:41:22 -0400, Tom Lane wrote:
>> Color me dubious.  Which specific other places have you got in mind, and
>> do they have expression trees at hand that would tell them which columns
>> they really need to pull out?

> I was thinking of execGrouping.c's execTuplesMatch(),
> TupleHashTableHash() (and unequal, but doubt that matters
> performancewise).  There's also nodeHash.c's ExecHashGetValue(), but I
> think that'd possibly better fixed differently.

The execGrouping.c functions don't have access to an expression tree
instructing them which columns to pull out of the tuple, so I fail to see
how get_last_attnums() would be of any use to them.  As for
ExecHashGetHashValue, it's most likely going to be working from virtual
tuples passed up to the join, which won't benefit from predetermination
of the last column to be accessed.  The tuple-deconstruction would have
happened while projecting in the scan node below.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] WIP: Faster Expression Processing v4
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [HACKERS] Odd listen_addresses behavior