From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 14:45:47 |
Message-ID: | 20121220144547.GE4303@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2012-12-20 09:11:46 -0500, Robert Haas wrote:
> On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > 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.
>
> I generally agree. We don't want to bloat the size of the parser with
> wild abandon, but yeah if we can reduce the cache misses on the
> well-travelled portions that seems like it ought to help. My previous
> hacky attempt to quantify the potential benefit in this area was:
>
> http://archives.postgresql.org/pgsql-hackers/2011-05/msg01008.php
>
> On my machine there seemed to be a small but consistent win; on a very
> old box Jeff Janes tried, it didn't seem like there was any benefit at
> all. Somehow, I have a feeling we're missing a trick here.
I don't think you will see too many cache misses on such a low number of
extremly simply statements, so its not too surprising not to see a that
big difference with that.
Are we sure its really cache-misses and not just the actions performed
in the grammar that make bison code show up in profiles? I remember the
latter being the case...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-20 14:51:37 | Re: Parser Cruft in gram.y |
Previous Message | Robert Haas | 2012-12-20 14:24:46 | recent ALTER whatever .. SET SCHEMA refactoring |