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  (Rod Taylor <rbt@rbt.ca>)
Parsing speed (was Re: pgstats_initstats() cost)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: pgstats_initstats() cost
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: threads/UnixWare