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 cou
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:
>
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg011
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 Wi
On Thu, Sep 17, 2009 at 12:24 PM, Tom Lane wrote:
> Jeff Janes 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-e
Jeff Janes 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 hypothesis that we
On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis 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 it looks l
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 tha
On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis 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 it looks l
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
Peter Eisentraut 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 lane
--
Sent
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 aggress
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
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 tra
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 like
On Mon, Aug 17, 2009 at 2:32 AM, Jeff Davis 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 aggressive) value on
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 already
16 matches
Mail list logo
