Re: Parser Cruft in gram.y - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Parser Cruft in gram.y
Date
Msg-id CA+U5nMJtTjb8DaaifXip0MiUcEK1R0un3Zvqmwo3NCqd03v0=g@mail.gmail.com
Whole thread Raw
In response to Re: Parser Cruft in gram.y  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parser Cruft in gram.y  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 18 December 2012 22:10, Robert Haas <robertmhaas@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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Parser Cruft in gram.y
Next
From: Amit Kapila
Date:
Subject: Re: ThisTimeLineID in checkpointer and bgwriter processes