2011/12/22 Tomas Vondra t...@fuzzy.cz:
The gettimeofday() calls are not exactly cheap in some cases, so why to
pay that price when all you need is the number of rows?
Fair point.
The patch attached does this:
1) adds INSTRUMENT_ROWS, a new InstrumentOption
- counts rows without timing
On 23.12.2011 14:57, Robert Haas wrote:
2011/12/22 Tomas Vondra t...@fuzzy.cz:
The gettimeofday() calls are not exactly cheap in some cases, so why to
pay that price when all you need is the number of rows?
Fair point.
The patch attached does this:
1) adds INSTRUMENT_ROWS, a new
Tomas Vondra t...@fuzzy.cz writes:
One thing I'm wondering about is that the InstrumentOptions are not
exclusive - INSTRUMENT_TIMER means 'collect timing and row counts' while
INSTRUMENT_ROWS means 'collect row counts'. Wouldn't it be better to
redefine the INSTRUMENT_TIMER so that it collects
Excerpts from Tomas Vondra's message of vie dic 23 11:45:40 -0300 2011:
One thing I'm wondering about is that the InstrumentOptions are not
exclusive - INSTRUMENT_TIMER means 'collect timing and row counts' while
INSTRUMENT_ROWS means 'collect row counts'. Wouldn't it be better to
redefine
On 23.12.2011 16:14, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
One thing I'm wondering about is that the InstrumentOptions are not
exclusive - INSTRUMENT_TIMER means 'collect timing and row counts' while
INSTRUMENT_ROWS means 'collect row counts'. Wouldn't it be better to
redefine
Tomas Vondra t...@fuzzy.cz writes:
The motivation for this patch was that collection timing data often
causes performance issues and in some cases it's not needed. But is this
true for row counts?
Perhaps more to the point, is there a use case for collecting timing
data without row counts? I
2011/12/23 Tom Lane t...@sss.pgh.pa.us:
Tomas Vondra t...@fuzzy.cz writes:
The motivation for this patch was that collection timing data often
causes performance issues and in some cases it's not needed. But is this
true for row counts?
Perhaps more to the point, is there a use case for
Pavel Stehule pavel.steh...@gmail.com writes:
2011/12/23 Tom Lane t...@sss.pgh.pa.us:
Tomas Vondra t...@fuzzy.cz writes:
The motivation for this patch was that collection timing data often
causes performance issues and in some cases it's not needed. But is this
true for row counts?
Perhaps
Dne 23.12.2011 22:37, Pavel Stehule napsal(a):
2011/12/23 Tom Lanet...@sss.pgh.pa.us:
Tomas Vondrat...@fuzzy.cz writes:
The motivation for this patch was that collection timing data often
causes performance issues and in some cases it's not needed. But is this
true for row counts?
Perhaps
2011/12/23 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/12/23 Tom Lane t...@sss.pgh.pa.us:
Tomas Vondra t...@fuzzy.cz writes:
The motivation for this patch was that collection timing data often
causes performance issues and in some cases it's not needed. But
Hello
2011/12/23 Tomas Vondra t...@fuzzy.cz:
Hi all,
most of the time I use auto_explain, all I need is duration of the query
and the plan with estimates and actual row counts. And it would be handy
to be able to catch long running queries with estimates that are
significantly off (say 100x
11 matches
Mail list logo