I assume no progress has been made on testing the performance of this
patch.
---
Jeff Davis wrote:
Attached is a patch to implement the idea discussed here:
On Tue, 2010-02-23 at 17:49 -0500, Bruce Momjian wrote:
I assume no progress has been made on testing the performance of this
patch.
That's correct. As of right now, the potential benefits of the patch do
not seem to justify the performance testing effort.
Others are welcome to try, of
On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote:
As always with patches that are meant to improve performance,
some experimental evidence would be a good thing.
I haven't had time to performance test this patch yet, and
Jeff Janes jeff.ja...@gmail.com writes:
Does the community think that experimental performance testing is a
must-have in order for this patch to be acceptable?
Dunno about others, but I think so. It's complicating both the
implementation and the users-eye view of VACUUM, and I want more than
a
On Thu, Sep 17, 2009 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Does the community think that experimental performance testing is a
must-have in order for this patch to be acceptable?
Dunno about others, but I think so. It's complicating both the
On Thu, 2009-09-17 at 12:36 -0400, Robert Haas wrote:
Despite my recent screw-up in this department, it should really be the
patch author's responsibility to test the patch first. Then the
reviewing process can involve additional testing. So I would say this
should be moved to Returned With
On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote:
As always with patches that are meant to improve performance,
some experimental evidence would be a good thing.
I haven't had time to performance test this patch yet, and
On Tue, 2009-09-15 at 20:56 -0700, Jeff Janes wrote:
Under what kind of circumstances/workload to you think this patch is
most likely to show its full potential? I can try to test it out, but
would like some guidance. I am guessing it is when the anti-wrap
around vacuums come due, but that
On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote:
As always with patches that are meant to improve performance,
some experimental evidence would be a good thing.
I haven't had time to performance test this patch yet, and it looks like
it will take a significant amount of effort to do so. I'm
On Sun, 2009-08-16 at 18:32 -0700, Jeff Davis wrote:
If VACUUM freezes one tuple on a page, it's likely that there are others
on the same page that are close to vacuum_freeze_min_age, but not quite.
Because the page is already dirty from freezing one tuple, it makes
sense to be more aggressive
Peter Eisentraut pete...@gmx.net writes:
The patch might make sense anyway, but I think it might not be such an
overwhelming winner in practice.
As always with patches that are meant to improve performance,
some experimental evidence would be a good thing.
regards, tom
Attached is a patch to implement the idea discussed here:
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01137.php
If VACUUM freezes one tuple on a page, it's likely that there are others
on the same page that are close to vacuum_freeze_min_age, but not quite.
Because the page is
On Mon, Aug 17, 2009 at 2:32 AM, Jeff Davispg...@j-davis.com wrote:
This patch introduces a GUC vacuum_freeze_opportunistic_ratio. If one
tuple on a page is frozen by vacuum, it effectively multiplies
vacuum_freeze_min_age by vacuum_freeze_opportunistic_ratio and uses that
lower (more
Looking at the patch I didn't like that duplicated the page scan in a
second function without refactoring out the first scan. I think this
comes from the usual noncommiter-itus of trying to modify the existing
code as little as possible. At least that's the problem I've had which
led to things
On Mon, 2009-08-17 at 04:01 +0100, Greg Stark wrote:
If it's convenient to have a function to handle the scan then use it
for both scans. You could have a flag that indicates it should abort
after the first freeze. I think it would be simpler to have a return
value indicating the oldest
On Mon, 2009-08-17 at 03:43 +0100, Greg Stark wrote:
I thought Josh's idea to apply this opportunistic threshold if the
page is already dirty for any reason was a good idea.
Is there a good way to tell if a buffer is dirty or not?
I don't see an exported function to do that. I could check by
16 matches
Mail list logo
