[HACKERS] Summer of Code idea

2006-04-27 Thread Jesper Pedersen
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

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Martijn van Oosterhout
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 parser

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Alvaro Herrera
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

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Jonah H. Harris
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

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Stephen Frost
* 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 could

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Tom Lane
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 much as

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Jonah H. Harris
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 parser

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Jonah H. Harris
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 remove

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Christopher Kings-Lynne
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.

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Jonah H. Harris
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

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Alvaro Herrera
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 easier to

Re: [HACKERS] Summer of Code idea

2006-04-27 Thread Jonah H. Harris
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