Re: [HACKERS] gperf anyone?
От | Alfred Perlstein |
---|---|
Тема | Re: [HACKERS] gperf anyone? |
Дата | |
Msg-id | 20000118213249.R8736@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] gperf anyone? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] gperf anyone?
|
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [000118 21:10] wrote: > > At 07:36 PM 1/18/00 -0500, Bruce Momjian wrote: > > I wondered about this last, i.e. the use of GNU code since Postgres > > is licensed differently. > > AFAIK this is no worse than using flex or bison --- the source code of > gperf is GPL'ed, but its output is not. > > Don Baccus <dhogaza@pacifier.com> writes: > > Whether faster or slower, though, I can't imagine either method taking > > noticably more than 0% of the total time to process a query, even the > > most simple queries. > > I agree with Don that the performance benefit is likely to be > unmeasurable. Still, there could be a win: we currently have to modify > keywords.c by hand every time we have to add/delete a keyword. Does > gperf offer any aid for maintaining the keyword list? If so, that'd > be sufficient reason to switch to it... any minimal performance boost shows over time, unfortunatly using gperf will require that you either: a) require gperf to be installed on a system that compiles postgresql b) manually maintain the gperf compiled files in your CVS repo (sort of like syscalls in FreeBSD) Option B is not that bad at the expense of additional contributor overhead. I hope to be able to present some soft of bench to determine if gperf is worth the additional effort of maintainance in the near future. in the meanwhile, happy hacking. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
В списке pgsql-hackers по дате отправления: