Skip site navigation (1) Skip section navigation (2)

Re: EXPLAIN progress info

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: EXPLAIN progress info
Date: 2008-04-10 09:48:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> 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 some complicated method, and the patch
> will be rejected because it adds too much overhead.  Anything we do here
> has to be cheap enough that no one will object to having it turned on
> all the time --- else it'll be useless exactly when they need it.

Actually Dave made a brilliant observation about this when I described it.
Most nodes can actually estimate their progress without any profiling overhead
at all. In fact they can do so more accurately than using the estimated rows.

Sequential scans, for example, can base a report on the actual block they're
on versus the previously measured end of the file. Bitmap heap scans can
report based on the number of blocks queued up to read.

Index scans are the obvious screw case. I think they would have to have a
counter that they increment on every tuple returned and reset to zero when
restarted. I can't imagine that's really a noticeable overhead though. Limit
and sort would also be a bit tricky.

  Gregory Stark
  Ask me about EnterpriseDB's 24x7 Postgres support!

In response to

pgsql-patches by date

Next:From: Teodor SigaevDate: 2008-04-10 11:53:32
Subject: Re: Partial match in GIN
Previous:From: Gregory StarkDate: 2008-04-10 09:02:10
Subject: Re: Concurrent psql API

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group