Re: multiset patch review - Mailing list pgsql-hackers

From Tom Lane
Subject Re: multiset patch review
Date
Msg-id 28774.1297439419@sss.pgh.pa.us
Whole thread Raw
In response to Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: multiset patch review  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SSI bug?
Next
From: Jan Urbański
Date:
Subject: Re: pl/python invalidate functions with composite arguments