Gregory Stark <stark@enterprisedb.com> 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 fantasy about what the
client-side code might be able to handle. Particularly if it's buried
inside, say, httpd or some huge Java app. Yeah, you could possibly make
it work for the case that the problem query was manually executed in
psql, but that doesn't cover very much real-world territory.
You'd be far more likely to get somewhere with a design that involves
looking from another session to see if anything's happening. In the
case of queries that are making database changes, pgstattuple is
certainly a usable option. For SELECT-only queries, I agree it's
harder, but it's still possible. I seem to recall some discussion of
including a low-overhead progress counter of some kind in the
pg_stat_activity state exposed by a backend. The number of rows so far
processed by execMain.c in the current query might do for the
definition.
regards, tom lane