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
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 for
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
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 the
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
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
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 t
Ü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.
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
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 large tales with relatively small hot spots. The basic problem
b
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 restri
> [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 kind of vacuum to only tables which h
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
it cares about is matching TIDs. The retail-vacuu
Tom, I ran your tests with fsync off (as you did), and saw numbers
bouncing between 400-700 tps without my patch, and sticking at 700 tps
with my patch.
---
Bruce Momjian wrote:
>
> The attached patch requires the new row t
The attached patch requires the new row to fit, and 10% to be free on
the page. Would someone test that?
---
Tom Lane wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > This is a revised patch originated by Junji TER
On Mon, 24 Jul 2006, Tom Lane wrote:
Personally I don't think retail vacuuming in that form will ever fly
anyway, so I have no problem with installing the proposed patch,
but I thought I'd better throw this comment out to see if anyone
thinks it's a big deal.
My feeling is that retail vacuumin
16 matches
Mail list logo