Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
> > How hard would it be to have Postgres actually remove the gettimeofday
> > overhead from the EXPLAIN ANALYZE output?
>
> Personally, I dislike measurement tools that lie to you under the flag
> of producing more-
Greg Stark <[EMAIL PROTECTED]> writes:
> How hard would it be to have Postgres actually remove the gettimeofday
> overhead from the EXPLAIN ANALYZE output?
Personally, I dislike measurement tools that lie to you under the flag
of producing more-easily-interpreted results.
As an example of why th
Tom Lane <[EMAIL PROTECTED]> writes:
> The EXPLAIN ANALYZE overhead for the Append is still pretty heavy,
> but when comparing actual runtimes for the two queries, they are
> now very nearly the same.
How hard would it be to have Postgres actually remove the gettimeofday
overhead from the EXPLAI
Sokolov Yura <[EMAIL PROTECTED]> writes:
> I think, postgres can perfoms aggregate on each table in union first,
> and then merge results.
I looked into this because it did not make a lot of sense to me. The
aggregates you are testing with (count, sum, max) are all perfectly
linear in the number
Hello, pgsql-hackers.
I have an idea ( :-) ) about
SELECT field1,agregate(field2) FROM view GROUP BY field1;
(and its variant SELECT agragate(field2) FROM view)
where view is SELECT ... UNION ALL ... :
As i understood from thread
http://archives.postgresql.org/pgsql-performance/2004-1
