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 *decrease*
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
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 my
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
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
13 matches
Mail list logo
