On 4/27/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Is the source easier to maintain?
Yes, aside from extra lookahead, that was my main motivation.
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
---(end of broadcast)---
Jonah H. Harris wrote:
> On 4/27/06, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> > Is it faster? How much faster?
>
> I'm not sure, I haven't done direct timings on it vs. the bison
> version. When I wrote it, I wasn't really concerned with the time it
> took to parse.
Is the source ea
On 4/27/06, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> Is it faster? How much faster?
I'm not sure, I haven't done direct timings on it vs. the bison
version. When I wrote it, I wasn't really concerned with the time it
took to parse.
--
Jonah H. Harris, Database Internals Architect
En
For the sake of saying again, I already have a recursive-descent
parser for PostgreSQL written in a PCCTS grammar. It's something I
started writing years ago, but I'd be willing to consider open
sourcing it if the PostgreSQL community will really entertain the
thought of switching.
Unfortunately
On 4/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> ... and is far more maintainable than an RD parser, and is not a
> performance bottleneck. I've never seen yyparse occupy as much as 2%
> of a backend profile ...
Not more maintainable by any stretch of the imagination. For example,
try and remov
On 4/27/06, Stephen Frost <[EMAIL PROTECTED]> wrote:
> The answer to that can certainly be "performance" provided other factors
> (such as maintainability) don't change much. If you could show that
> then I think such a switch would be very seriously considered.
IMHO, switching parser-types (and
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Unfortunately, this discussion usually ends up with, "why would we
> want to change what we have now when it already works?"
... and is far more maintainable than an RD parser, and is not a
performance bottleneck. I've never seen yyparse occupy as m
* Jonah H. Harris ([EMAIL PROTECTED]) wrote:
> Unfortunately, this discussion usually ends up with, "why would we
> want to change what we have now when it already works?"
The answer to that can certainly be "performance" provided other factors
(such as maintainability) don't change much. If you
On 4/27/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> We talked about it when GCC announced their switch. The conclusion was
> that our grammar is still too much a moving target, so it would be too
> difficult to mantain such a grammar.
For the sake of saying again, I already have a recursive-d
Jesper Pedersen wrote:
> I have been thinking about this for a while and now that Google Summer of Code
> is coming I thought I would share this idea.
>
> The GCC people have traded their bison/flex parser with a hand written
> recursive-descent parser for a nice speed up.
>
> So it would be int
On Tue, Apr 25, 2006 at 10:30:26PM +0200, Jesper Pedersen wrote:
> Hi.
>
> I have been thinking about this for a while and now that Google Summer of Code
> is coming I thought I would share this idea.
>
> The GCC people have traded their bison/flex parser with a hand written
> recursive-descent p
Hi.
I have been thinking about this for a while and now that Google Summer of Code
is coming I thought I would share this idea.
The GCC people have traded their bison/flex parser with a hand written
recursive-descent parser for a nice speed up.
So it would be interesting to see if PostgreSQL wou
12 matches
Mail list logo
