did you happen to take a look at the other set of queries I sent you, that
were showing 39k and 41k explain results? do they show pretty much the
same 'lag' in gettimeofday()?
On Fri, 28 Nov 2003, Tom Lane wrote:
> > ... if its just me mis-reading the numbers, let me
> > know ... it just "feels
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> did you happen to take a look at the other set of queries I sent you, that
> were showing 39k and 41k explain results?
You mean this one?
> time psql -c "explain analyze select max(intag) from ndict3" 186_archives
Tom, I am afraid that I don't understand. My first example:
wow=# explain analyze select max(click.accesses) from click;
QUERY PLAN
-
A
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > did you happen to take a look at the other set of queries I sent you, that
> > were showing 39k and 41k explain results?
>
> You mean this one?
Yup ...
> > time psql -c "explain analyze select max(intag) fr
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Tom, I am afraid that I don't understand. My first example:
> wow=# explain analyze select max(click.accesses) from click;
> QUERY PLAN
> -
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>> Now that I recall, didn't you complain of something similar with a beta?
> Yup ... and I bet its not reproducible yet again, is it? :) That would
> make for twice though, with v7.4, that I've come up with - r
None that I've heard of ... Sean?
Tom, any way of writing a quite test C program for this? Something to
'simulate' the same thing, but without having to build the whole
postmaster?
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Fri, 28 Nov 2003, To
> ... if its just me mis-reading the numbers, let me
> know ... it just "feels" off
Here's what I see:
> time psql -c "explain analyze SELECT count(rec_id) FROM url" 186_archives
QUERY PLAN
--
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> How many times is gettimeofday called?
Twice per plan node visit, if you are doing EXPLAIN ANALYZE. (The
number of "visits" is one more than the number of rows returned.)
regards, tom lane
---(end of bro
How many times is gettimeofday called?
wow=# explain analyze select 1;
QUERY PLAN
Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.008..0.010 rows=1 loops=1)
Total ru
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Actually, I'm noticing similar "problems" with v7.4 ... "EXPLAIN ANALYZE"
> > seems to be showing some *very* high ms for execution time, but if you run
> > the actual query, it doesn't seem to take even 1/10
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Actually, I'm noticing similar "problems" with v7.4 ... "EXPLAIN ANALYZE"
> seems to be showing some *very* high ms for execution time, but if you run
> the actual query, it doesn't seem to take even 1/10th the time reported
> ...
Example? I don't
On Fri, 28 Nov 2003, Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Explain analyze takes 3 times more time for execution. Why?
>
> Measurement overhead. It would seem your platform has a particularly
> slow version of gettimeofday() though ... I've never noticed such a
> large d
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Explain analyze takes 3 times more time for execution. Why?
Measurement overhead. It would seem your platform has a particularly
slow version of gettimeofday() though ... I've never noticed such a
large discrepancy myself.
regar
Hello!
Explain analyze takes 3 times more time for execution. Why?
wow=# \timing
Timing is on.
wow=# select max(click.accesses) from click;
max
--
10944762
(1 row)
Time: 105,654 ms
wow=# explain analyze select max(click.accesses) from click;
15 matches
Mail list logo
