Re: Any better plan for this query?..
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 4A096D46.1080208@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Dimitri <dimitrik.fr@gmail.com>) |
Ответы |
Re: Any better plan for this query?..
|
Список | pgsql-performance |
Dimitri wrote: > Folks, before you start to think "what a dumb guy doing a dumb thing" :-)) > I'll explain you few details: > > it's for more than 10 years I'm using a db_STRESS kit > (http://dimitrik.free.fr/db_STRESS.html) to check databases > performance and scalability. Until now I was very happy with results > it gave me as it stress very well each database engine internals an > put on light some things I should probably skip on other workloads. > What do you want, with a time the "fast" query executed before in > 500ms now runs within 1-2ms - not only hardware was improved but also > database engines increased their performance a lot! :-)) I was attempting to look into that "benchmark" kit a bit but I find the information on that page a bit lacking :( a few notices: * is the sourcecode for the benchmark actually available? the "kit" seems to contain a few precompiled binaries and some source/headfiles but there are no building instructions, no makefile or even a README which makes it really hard to verify exactly what the benchmark is doing or if the benchmark client might actually be the problem here. * there is very little information on how the toolkit talks to the database - some of the binaries seem to contain a static copy of libpq or such? * how many queries per session is the toolkit actually using - some earlier comments seem to imply you are doing a connect/disconnect cycle for every query ist that actually true? Stefan
В списке pgsql-performance по дате отправления: