From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: LRU |
Date: | 2005-01-25 00:22:23 |
Message-ID: | 1106612543.1780.46.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Mon, 2005-01-24 at 18:43 -0500, Tom Lane wrote:
> Well, the thing that's bothering me is that you are undoing a number of
> changes that we'll probably just have to redo later; with consequently
> *two* chances to introduce bugs.
I'm not sure if we should apply this patch to both HEAD and
REL8_0_STABLE, or just the latter. I would guess there is no IP reason
to remove ARC from HEAD as well; while it might introduce complications
in backporting changes from HEAD, those same complications were present
through most of the 8.0 cycle (i.e. HEAD used a different replacement
policy than REL7_4_STABLE did).
> If the problem is that the current freelist.c API exposes too much about
> the ARC implementation, the answer to that is not to go back to exposing
> the LRU-list implementation; it's to generalize the API.
That would be one approach, yeah. My goal was to keep the code simple
and reasonably similar to the 7.4 codebase (which has gotten a lot more
testing than the ARC code, in addition to the fact that the ARC APIs
aren't really appropriate for an LRU implementation). Worrying about the
right freelist.c APIs seemed a little beside the point -- I didn't want
to make _any_ assumptions about how the code is going to look in 8.1, as
it may be fundamentally different.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-01-25 00:27:12 | Re: pg_autovacuum Win32 Service startup delay |
Previous Message | Tom Lane | 2005-01-24 23:57:54 | Re: pg_autovacuum Win32 Service startup delay |