On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 18 December 2012 22:10, Robert Haas <robertmh...@gmail.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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
