"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 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 EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
