I didn't think pgstattuple had proper visibility checks.
---
Hans-Jürgen Schönig wrote:
This patch adds a note to the documentation describing why the
performance of min() and max() is slow when applied to the entire
Bruce Momjian [EMAIL PROTECTED] writes:
I didn't think pgstattuple had proper visibility checks.
It doesn't, see followup discussion.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
But pgstattuple does do a sequential scan of the table. You avoid a lot
of the executor's tuple-pushing and plan-node-traversing machinery that
way, but the I/O requirement is going to be exactly the same.
I have tried it more often so that I can be sure that everything is in
the cache.
I
For a more accurate view of the time used, use the \timing switch in psql.
That leaves out the overhead for forking and loading psql, connecting to
the database and such things.
I think, that it would be even nicer if postgresql automatically choose
to replace the count(*)-with-no-where with
On Sun, 2003-02-02 at 03:55, Hans-Jürgen Schönig wrote:
If people want to count ALL rows of a table. The contrib stuff is pretty
useful. It seems to be transaction safe.
Interesting -- I didn't know about the contrib stuff. I'll update the
docs patch.
Cheers,
Neil
--
Neil Conway [EMAIL
On Sun, 2003-02-02 at 13:04, Tom Lane wrote:
I think your test case is small enough that the whole table is resident
in memory, so this measurement only accounts for CPU time per tuple and
not any I/O. Given the small size of pgstattuple's per-tuple loop, the
speed differential is not too
