Re: A costing analysis tool

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, tgl(at)sss(dot)pgh(dot)pa(dot)us, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: A costing analysis tool
Date: 2005-10-15 21:53:45
Message-ID: 87br1qfnva.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:

> This is unfortunate because EXPLAIN ANALYZE is an immensly useful tool,
> as far as it goes. I've pondered if some kind of userspace timing
> mechanism could be introduced (possibly using builtin CPU cycle
> counters) to reduce the cost. It does, however, remain a cost.

I wonder if there's a good case for a version of explain analyze that runs the
query and outputs the plan along with row counts but not timing for each row.
You would still be able to see if the estimates are correct. And it would have
basically no overhead so you could use it under a production environment.

> Given that you can see how many times gettimeday() was called, you may
> be able to correct the error. I havn't tried that though.

I tried, it seems like it should be trivial but I got bogged down in details.
Removing profiling overhead is pretty standard for profilers to do though. It
really seems to me like it ought to be done. It still wouldn't let you use
EXPLAIN ANALYZE under production without a lot of overhead though.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-15 22:06:01 Re: A costing analysis tool
Previous Message Greg Stark 2005-10-15 21:50:26 Re: A costing analysis tool