| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: multiset patch review |
| Date: | 2011-02-11 15:50:19 |
| Message-ID: | 28774.1297439419@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-02-11 15:50:47 | Re: REVIEW: Determining client_encoding from client locale |
| Previous Message | Jan Urbański | 2011-02-11 15:49:36 | Re: pl/python custom datatype parsers |