I like this idea in general. I'm envisioning a cool explain display in
pgAdmin that's updated live, as the query is executed, showing how many
tuples a seq scan in the bottom, and an aggregate above it, has
processed. Drool.
Currently the interface is that you open a new connection, and
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I think a better way to get a real percentage done would be to add a method
to each node which estimates its percentage done based on the percentage done
its children report and its actual and expected rows and its
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
There are downsides:
Insurmountable ones at that. This one already makes it a non-starter:
a) the overhead of counting rows and loops is there for every query execution,
even if you don't do explain analyze.
and you are also
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
There are downsides:
Insurmountable ones at that. This one already makes it a non-starter:
a) the overhead of counting rows and loops is there for every query
execution,
even if you
Gregory Stark [EMAIL PROTECTED] writes:
I think a better way to get a real percentage done would be to add a method
to each node which estimates its percentage done based on the percentage done
its children report and its actual and expected rows and its costs.
You can spend a week inventing
Not to be opened before May 1st!
I know I should still be looking at code from the March Commitfest but I was
annoyed by this *very* FAQ:
http://archives.postgresql.org/pgsql-general/2008-04/msg00402.php
This also came up at the UKUUG-Pg conference so it was already on my mind. I
couldn't
Gregory Stark [EMAIL PROTECTED] writes:
I know I should still be looking at code from the March Commitfest but I was
annoyed by this *very* FAQ:
http://archives.postgresql.org/pgsql-general/2008-04/msg00402.php
Seems like pg_relation_size and/or pgstattuple would solve his problem
better,
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I know I should still be looking at code from the March Commitfest but I was
annoyed by this *very* FAQ:
http://archives.postgresql.org/pgsql-general/2008-04/msg00402.php
Seems like pg_relation_size and/or
Gregory Stark [EMAIL PROTECTED] writes:
There are downsides:
Insurmountable ones at that. This one already makes it a non-starter:
a) the overhead of counting rows and loops is there for every query execution,
even if you don't do explain analyze.
and you are also engaging in a flight of
