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
|
Список | 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 по дате отправления: