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

Re: [HACKERS] dollar quoting

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,"Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] dollar quoting
Date: 2004-02-17 03:16:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I am a little concerned about adding the overhead of lex to psql.  Right
> > now, some folks have reported that lex/yacc take a considerable amount
> > of processing time in the backend as part of a query, and adding that to
> > psql just to do $$ seems questionable.  Of course, we can alway test and
> > see what the overhead shows.
> That's not the question to ask --- the question is whether a flex lexer
> will be faster or slower than the hand-made lexing code that psql is
> currently using.  Lexer generation is a well-understood art, and you
> have to be pretty tense to beat out flex with hand-made code.  It's the
> same tradeoff as trying to write better assembly code than a compiler
> does.  Look at the lexing loop in psql/mainloop.c (that series of
> if-tests starting at about line 250) and ask yourself if that's really
> going to beat out the state-machine implementation flex uses --- which
> looks to be about two table lookups per character, plus a switch()
> executed at the end of every token.  I'll bet on flex being faster.
> The reason the lexer shows up in the backend is that it has to grovel
> over every individual character of a query.  For sufficiently large
> query strings that's gonna take awhile no matter how you do it.
> But in any case, the argument for moving to flex is not about
> performance, it is about making the code more understandable and more
> certain to agree with the backend lexer.

If we go with lex/flex for psql, I would still like someone to test
performance to see that we aren't taking a big hit.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Neil ConwayDate: 2004-02-17 03:39:35
Subject: casting zero-length strings
Previous:From: Tom LaneDate: 2004-02-17 02:54:52
Subject: Re: [PATCHES] dollar quoting

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-02-17 03:34:49
Subject: Re: contrib/dbmirror
Previous:From: Neil ConwayDate: 2004-02-17 03:00:49
Subject: fix oid casting inconsistency

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