OK, removed from open item list.
---
Tom Lane wrote:
> 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
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:
> Tom, should I apply this patch now? Are you still considering other
> options for this?
Please wait. This issue is very far down the to-list in terms of size
or significance ... but I'll get to it.
regards, tom lane
--
Tom, should I apply this patch now? Are you still considering other
options for this?
---
Bruce Momjian wrote:
>
> Tom, I ran your tests with fsync off (as you did), and saw numbers
> bouncing between 400-700 tps without m
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 Lane <[EMAIL PROTECTED]> writes:
> 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 hi
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
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-atim
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
tha
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
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
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-atim
24 matches
Mail list logo
