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
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 ta
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 som
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 t
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
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> In special cases there can be another way to avoid seq scans:
> [ use pgstattuple() ]
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 t
Neil Conway wrote:
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
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 P
This patch adds a note to the documentation describing why the
performance of min() and max() is slow when applied to the entire table,
and suggesting the simple workaround most experienced Pg users
eventually learn about (SELECT xyz ... ORDER BY xyz LIMIT 1).
Any suggestions on improving the word
