Re: multiset patch review

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: multiset patch review
Дата
Msg-id 28774.1297439419@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: multiset patch review  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Right, but making the parser slower has a cost, too.
> ScanKeywordLookup() is already a hotspot in some workloads, and
> there's overhead buried in the bison parser, too.

Yeah.  Keep in mind that a bison parser fundamentally runs off a
two-dimensional array: one axis is parser state and the other is token
number.  They have some tricks to compress the array a bit, but adding
keywords contributes directly to a bigger array, which means slower
parsing (more L1 cache misses).  The parser's inner loop frequently
shows up as a hotspot in profiles I do, and I think that has to be more
about the amount of data it's touching than the cost of the loop per se.

Adding unnecessary keywords is something to be avoided.
        regards, tom lane


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI bug?
Следующее
От: Jan Urbański
Дата:
Сообщение: Re: pl/python invalidate functions with composite arguments