Re: A couple of issues with psql variable substitution
От | Alvaro Herrera |
---|---|
Тема | Re: A couple of issues with psql variable substitution |
Дата | |
Msg-id | 1314292430-sup-2544@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: A couple of issues with psql variable substitution (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A couple of issues with psql variable substitution
|
Список | pgsql-hackers |
Excerpts from Tom Lane's message of jue ago 25 14:00:57 -0300 2011: > Robert Haas <robertmhaas@gmail.com> writes: > > On Thu, Aug 25, 2011 at 12:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> 1. Somebody broke the no-backtracking property back in 9.0 while adding > >> quoted variable substitution. According to the flex manual, use of > >> backtracking creates a performance penalty. We once measured the > >> backend's lexer as being about a third faster with backtrack avoidance, > >> and presumably it's about the same for psql's. This is not hard to fix, > >> but should I consider it a bug fix and back-patch? We've not had > >> complaints about psql getting slower as of 9.0. > > > That may well have been me. > > [ checks "git blame" ] Well, you commmitted the patch anyway: d0cfc018. > > > How would I have known that I broke it? > > Per the header comments in the backend lexer, you should run flex with > "-b" switch and verify that the resulting lex.backup file says "no > backing up". I've occasionally thought about automating that, but I'm > not sure if the output is entirely locale- and flex-version-independent. It is locale dependent, though of course for the automated check you could just run flex under LC_ALL=C. $ /usr/bin/flex -Cfe -b /pgsql/source/REL8_4_STABLE/src/bin/psql/psqlscan.l $ cat lex.backup Sin retroceso. $ LC_ALL=C /usr/bin/flex -Cfe -b /pgsql/source/REL8_4_STABLE/src/bin/psql/psqlscan.l $ cat lex.backup No backing up. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: