Re: pgstats_initstats() cost
От | Gavin Sherry |
---|---|
Тема | Re: pgstats_initstats() cost |
Дата | |
Msg-id | Pine.LNX.4.21.0308121233390.31574-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: pgstats_initstats() cost ("Andrew Dunstan" <andrew@dunslane.net>) |
Ответы |
Re: pgstats_initstats() cost
Parsing speed (was Re: pgstats_initstats() cost) |
Список | pgsql-hackers |
On Mon, 11 Aug 2003, Andrew Dunstan wrote: > > ----- Original Message ----- > From: "Gavin Sherry" <swm@linuxworld.com.au> > > I am still researching ways of increasing performance of yacc parsers -- > > there is a very small amount of information on the Web concerning this -- > > I know some people who will tell you that the best way of improving > performance in this area is not to use yacc (or bison) parsers ... Yes. Cost of maintenance vs. performance cost... > > OTOH we need to understand exactly what you were profiling - if it is 1 > dynamic sql statement per insert then it might not be too close to the real > world - a high volume program is likely to require 1 parse per many many > executions, isn't it? I wasn't interested in measuring the performance of yacc -- since I know it is bad. It was a basic test which wasn't even meant to be real world. It just seemed interesting that the numbers were three times slower than other databases I ran it on. Here is the script which generates the SQL: echo "create table abc(t text);" echo "begin;" c=0 while [ $c -lt 100000 ] do echo "insert into abc values('thread1');"; c=$[$c+1] done echo "commit;" Thanks, Gavin
В списке pgsql-hackers по дате отправления: