Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've applied this but I'm now having some second thoughts about it,
because I'm seeing an actual *decrease* in pgbench numbers from the
immediately prior CVS HEAD code.
The attached patch requires the new row to fit, and 10% to be free
Have we made a decision on this issue? Should I apply my patch that
still forces a split unless 10% of the page has been freed?
---
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a revised patch
Bruce Momjian [EMAIL PROTECTED] writes:
Have we made a decision on this issue? Should I apply my patch that
still forces a split unless 10% of the page has been freed?
I haven't gotten back to doing any more performance testing. Please
stick that patch on the pending queue, so we don't forget
On Thu, Jul 27, 2006 at 05:24:35PM -0400, Greg Stark wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Even if we stopped right there it would still be a huge win in many (most?)
cases. How often do the indexes on a table comprise even 50% of the table's
size?
I would say they're usually
On Jul 26, 2006, at 4:29 PM, Hannu Krosing wrote:
Well the desire for it comes from a very well established need
for dealing
with extremely large tales with relatively small hot spots. The
basic problem
being that currently the cost of vacuum is proportional to the
size of the
table rather
On Jul 26, 2006, at 10:29 AM, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point
here is
that the existing vacuum does not rely on re-computing index keys; all
Jim Nasby [EMAIL PROTECTED] writes:
Even if we stopped right there it would still be a huge win in many (most?)
cases. How often do the indexes on a table comprise even 50% of the table's
size?
I would say they're usually roughly comparable actually. It depends on how
wide your table is
Csaba Nagy [EMAIL PROTECTED] writes:
[snip] (In fact, it's
trivial to see how user-defined functions that are mislabeled immutable
could make this fail.) So retail vacuum without any cross-check that
you got all the index tuples is a scary proposition IMHO.
Wouldn't work to restrict that
On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
So far, the case hasn't been made for retail vacuum even ignoring the
not-so-immutable-function risk.
Well the desire for it comes from a very well established need for dealing
with extremely
Ühel kenal päeval, K, 2006-07-26 kell 23:02, kirjutas Martijn van
Oosterhout:
On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
So far, the case hasn't been made for retail vacuum even ignoring the
not-so-immutable-function risk.
Well
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I think we can resurrect his idea because we will scan btree pages
at-atime now; the missing-restarting-point problem went away.
Have I missed something? Comments welcome.
I was thinking for awhile just now that this would break the interlock
that
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a revised patch originated by Junji TERAMOTO for HEAD.
[BTree vacuum before page splitting]
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
I think we can resurrect his idea because we will scan btree pages
at-atime now;
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a revised patch originated by Junji TERAMOTO for HEAD.
[BTree vacuum before page splitting]
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
I think we can resurrect his idea because we will scan btree pages
at-atime now;
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a revised patch originated by Junji TERAMOTO for HEAD.
[BTree vacuum before page splitting]
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
I think we can resurrect his idea because we will scan btree
On Thu, 2006-07-13 at 10:49 +0900, ITAGAKI Takahiro wrote:
This is a revised patch originated by Junji TERAMOTO for HEAD.
[BTree vacuum before page splitting]
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
I think we can resurrect his idea because we will scan btree
This is a revised patch originated by Junji TERAMOTO for HEAD.
[BTree vacuum before page splitting]
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
I think we can resurrect his idea because we will scan btree pages
at-atime now; the missing-restarting-point problem went
16 matches
Mail list logo
