On Sat, 2006-02-11 at 16:36 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I believe this is safe.
I won't insult your intelligence by pointing out how I know that you
didn't even test the patch against hash or gist.
I don't recall either way, though from what you say it
Patch applied. Thanks.
---
Simon Riggs wrote:
On Wed, 2005-12-07 at 17:40 +, Simon Riggs wrote:
On Wed, 2005-12-07 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We discussed an
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks.
Please revert. You cannot skip scanning indexes simply because there
was no heap activity. btree for instance does post-cleanup on the
next vacuum.
regards, tom lane
---(end
Simon Riggs [EMAIL PROTECTED] writes:
We discussed an optimization of VACUUM here
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00046.php
that would allow VACUUM to complete faster by avoiding scanning the
indexes when no rows were removed from the heap by the VACUUM.
After looking
On Sat, 2006-02-11 at 12:04 -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks.
Please revert. You cannot skip scanning indexes simply because there
was no heap activity. btree for instance does post-cleanup on the
next vacuum.
The patch skips
Simon Riggs [EMAIL PROTECTED] writes:
I believe this is safe.
I won't insult your intelligence by pointing out how I know that you
didn't even test the patch against hash or gist.
The major problem with the patch is that it's incapable of producing
correct tuple-count stats for partial indexes,
Here's the patch as-applied. Note one major difference from your
original: the logic about whether an indexscan can be skipped is now
entirely local to the index AMs, rather than allowing VACUUM to make
assumptions that may not be warranted for particular AMs. For the
same reason, the AM is
Simon Riggs [EMAIL PROTECTED] writes:
We discussed an optimization of VACUUM here
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00046.php
that would allow VACUUM to complete faster by avoiding scanning the
indexes when no rows were removed from the heap by the VACUUM.
Unfortunately
On Wed, 2005-12-07 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We discussed an optimization of VACUUM here
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00046.php
that would allow VACUUM to complete faster by avoiding scanning the
indexes when no rows
On Wed, 2005-12-07 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We discussed an optimization of VACUUM here
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00046.php
that would allow VACUUM to complete faster by avoiding scanning the
indexes when no rows
On Wed, 2005-12-07 at 17:40 +, Simon Riggs wrote:
On Wed, 2005-12-07 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We discussed an optimization of VACUUM here
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00046.php
that would allow VACUUM to
11 matches
Mail list logo
