Re: Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Parser Cruft in gram.y
Дата
Msg-id 20121214234149.80060@gmx.com
обсуждение исходный текст
Ответ на Parser Cruft in gram.y  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Parser Cruft in gram.y
Список pgsql-hackers
Tom Lane wrote:

> the parser tables are basically number-of-tokens wide by
> number-of-states high. (In HEAD there are 433 tokens known to the
> grammar, all but 30 of which are keywords, and 4367 states.)
> 
> Splitting the grammar into multiple grammars is unlikely to do
> much to improve this --- in fact, it could easily make matters
> worse due to duplication.

I agree that without knowing what percentage would be used by each
parser in a split, it could go either way.  Consider a hypothetical
situation where one parser has 80% and the other 50% of the current
combined parser -- 30% overlap on both tokens and grammer
constructs. (Picking numbers out of the air, for purposes of
demonstration.)

Combined = 433 * 4,367 = 1,890,911

80% = 346 * 3,493 = 1,208,578
50% = 216 * 2,183 =   471,528

Total for split =   1,680,106

Of course if they were both at 80% it would be a higher total than
combined, but unless you have a handle on the percentages, it
doesn't seem like a foregone conclusion. Do you have any feel for
what the split would be?

-Kevin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Gould
Дата:
Сообщение: Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors
Следующее
От: Andres Freund
Дата:
Сообщение: Re: logical decoding - GetOldestXmin