Re: review: Non-recursive processing of AND/OR lists

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: review: Non-recursive processing of AND/OR lists
Дата
Msg-id CA+TgmoaRjAynkdrs3r2QEkcb1fk4_3HvvoqCehWB_7mLy+GGDA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: review: Non-recursive processing of AND/OR lists  (Gurjeet Singh <gurjeet@singh.im>)
Ответы Re: review: Non-recursive processing of AND/OR lists  (Gurjeet Singh <gurjeet@singh.im>)
Список pgsql-hackers
On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh <gurjeet@singh.im> wrote:
> Agreed that there's overhead in allocating list items, but is it more
> overhead than pushing functions on the call stack? Not sure, so I leave it
> to others who understand such things better than I do.

If you think that a palloc can ever be cheaper that pushing a frame on
the callstack, you're wrong.  palloc is not some kind of an atomic
primitive.  It's implemented by the AllocSetAlloc function, and you're
going to have to push that function on the call stack, too, in order
to run it.

My main point here is that if the user writes a = 1 and b = 1 and c =
1 and d = 1, they're not going to end up with a bushy tree.  They're
going to end up with a tree that's only deep in one direction (left, I
guess) and that's the case we might want to consider optimizing.  To
obtain a bushy tree, they're going to have to write a  = 1 and (b = 1
and c = 1) and d = 1, or something like that, and I don't see why we
should stress out about that case.  It will be rare in practice.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_filedump 9.3: checksums (and a few other fixes)
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)