Skip site navigation (1) Skip section navigation (2)

Re: Parser Cruft in gram.y

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(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 14:11:46
Message-ID: CA+TgmoZ8efZ1ESE4C55sGbu4nyqwMqtpqpejGmPnH-XSSfQ7Pg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-12-20 14:24:46
Subject: recent ALTER whatever .. SET SCHEMA refactoring
Previous:From: Amit KapilaDate: 2012-12-20 14:08:47
Subject: Re: ThisTimeLineID in checkpointer and bgwriter processes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group