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 signal
"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 ro
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 inven
"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
>>> ex
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 engagi
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
"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
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
bette
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 r
