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: 2791.1148686990@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-hackers by date

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