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

Re: Updatable views/with check option parsing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: peter_e(at)gmx(dot)net, kleptog(at)svana(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updatable views/with check option parsing
Date: 2006-05-26 23:43:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> As I understand it, it runs one parser pretty much like the standard LALR(1)
> case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which
> stage it clones the parser to take parallel paths, working in lockstep, and
> storing up semantic actions. When one of the clones encounters an error it
> goes away, and the surviving clone takes its stored semantic actions. If
> that's true, then probably the only significant performance hit is in cases
> of ambiguity, and we would only have a handful of those, each lasting for
> one token, so the performance hit should be very small. We'd have to test
> it, of course ;-)

Yeah, I just read the same in the bison manual.  The thing that's
bothering me is that a GLR parser would hide that ambiguity from you,
and thus changes in the grammar might cause us to incur performance
hits without realizing it.  The manual indicates that the performance
is pretty awful whenever an ambiguity does occur.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-05-26 23:59:29
Subject: Re: Updatable views/with check option parsing
Previous:From: Mark WoodwardDate: 2006-05-26 23:32:43
Subject: Re: LIKE, leading percent, bind parameters and indexes

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