| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)mail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Parser Cruft in gram.y |
| Date: | 2012-12-20 13:55:40 |
| Message-ID: | CA+U5nMJtTjb8DaaifXip0MiUcEK1R0un3Zvqmwo3NCqd03v0=g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18 December 2012 22:10, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Well that would be nice, but the problem is that I see no way to
> implement it. If, with a unified parser, the parser is 14% of our
> source code, then splitting it in two will probably crank that number
> up well over 20%, because there will be duplication between the two.
> That seems double-plus un-good.
I don't think the size of the parser binary is that relevant. What is
relevant is how much of that is regularly accessed.
Increasing parser cache misses for DDL and increasing size of binary
overall are acceptable costs if we are able to swap out the unneeded
areas and significantly reduce the cache misses on the well travelled
portions of the parser.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2012-12-20 14:08:47 | Re: ThisTimeLineID in checkpointer and bgwriter processes |
| Previous Message | Peter Eisentraut | 2012-12-20 13:47:52 | Re: Parser Cruft in gram.y |