Re: [HACKERS] COUNT and Performance ...

2003-02-17 Thread Bruce Momjian
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

Re: [HACKERS] COUNT and Performance ...

2003-02-17 Thread Tom Lane
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

Re: [HACKERS] COUNT and Performance ...

2003-02-06 Thread Hans-Jürgen Schönig
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

Re: [HACKERS] COUNT and Performance ...

2003-02-06 Thread Arjen van der Meijden
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

[HACKERS] COUNT and Performance ...

2003-02-02 Thread Hans-Jürgen Schönig
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

Re: [HACKERS] COUNT and Performance ...

2003-02-02 Thread Neil Conway
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

Re: [HACKERS] COUNT and Performance ...

2003-02-02 Thread Neil Conway
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