Tom Lane <tgl@xxxxxxxxxxxxx> writes:
> Would it? My first thought on reading the OP was to recommend
> contrib/pgstattuple, but I refrained after thinking that if the table
> is all that big, the last thing you need is someone doing a seqscan of
> the whole table to see where you are. Much less doing so repeatedly.
Well it's not a magic bullet, but there are lots of circumstances where it
would be useful.
I used to load huge data sets into Oracle from text files. These are purely
insert only, reading the table contents isn't really going to interfere much
with the load operation.
Sometimes I do large queries that seem to take longer than I expect. It would
be useful to be able to look at the data to be sure it isn't off doing
something entirely inappropriate like an unconstrained join or a join on the
wrong columns.
The application where it would be really invaluable is when you want a web
page that displays a progress bar or monitoring software for some running job
(triggered either from the web application or a cron job). Normally you
wouldn't be able to do this unless you were willing to have the job commit
periodically or jury rig up something effectively equivalent to READ DIRTY
involving temporary files or extra database connections. Any progress
information the job has available to it isn't available to the web
application or monitoring software.
I would say this doesn't replace having some sort of progress indication from
SQL queries. It's an entirely separate feature that happens to be useful for
some of the same uses. There are certainly pros and cons of each approach for
various use cases.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
