Re: That EXPLAIN ANALYZE patch still needs work
От | Simon Riggs |
---|---|
Тема | Re: That EXPLAIN ANALYZE patch still needs work |
Дата | |
Msg-id | 1149754621.2680.95.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: That EXPLAIN ANALYZE patch still needs work (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: That EXPLAIN ANALYZE patch still needs work
|
Список | pgsql-hackers |
On Wed, 2006-06-07 at 17:28 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Wed, 2006-06-07 at 16:56 -0400, Tom Lane wrote: > >> Certainly the removal of timing > >> is not going to convert an intolerable EXPLAIN ANALYZE runtime into an > >> acceptable one; > > > I disagree, as have others. > > The overhead seems to be on the order of a couple tens of percent usually. > I don't see how that makes the difference between an EXPLAIN ANALYZE you > can run and one you can't. Well, thats not my experience and doesn't match others posted on -hackers. A simple test with pgbench shows the timing overhead of EXPLAIN ANALYZE to be consistently above 500% (or more than +400%, depending upon how you style those numbers). This is for in-shared-buffers data, following cache priming. Test shown below is typical result from 5 tests: > postgres=# select count(*) from accounts; > count > -------- > 100000 > (1 row) > > Time: 267.008 ms > postgres=# explain analyze select count(*) from accounts; > QUERY PLAN > ----------------------------------------------------------------------------------------------------------------------- > Aggregate (cost=10945.00..10945.01 rows=1 width=0) (actual time=1497.830..1497.837 rows=1 loops=1) > -> Seq Scan on accounts (cost=0.00..9998.20 rows=378720 width=0) (actual time=0.078..828.455 rows=100000 loops=1) > Total runtime: 1497.954 ms > (3 rows) > > Time: 1498.983 ms Other timings were: 1493 1498 1707 1814 1827 EXPLAIN ANALYZE is designed to be run *when* you have unacceptable run times and need to find out why. So making the execution time even more unacceptable makes the utility infeasible at the time you need it most. The additional run-time occurs on people's production systems, so they generally aren't happy running long tasks. BTW I think EA is great - so good in fact I want to run it more often. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: