Re: Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Parser Cruft in gram.y
Дата
Msg-id CA+U5nMJtTjb8DaaifXip0MiUcEK1R0un3Zvqmwo3NCqd03v0=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parser Cruft in gram.y  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parser Cruft in gram.y
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Parser Cruft in gram.y
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: ThisTimeLineID in checkpointer and bgwriter processes