From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch queue triage |
Date: | 2007-05-03 08:44:47 |
Message-ID: | 2e78013d0705030144n6d536f49s104c94f9dcb2ce6f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/2/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>
> Can we? I mean, sure you can break the patch up into chunks which might
> make
> it easier to read, but are any of the chunks useful alone?
Well I agree, it would be a tough job. I can try and break the patch into
several self-complete incremental patches which compile and work, but
I am worried about missing something somewhere and/or inserting
any bugs in the process.
> I suppose inserting HOT tuples without index maintenance is useful even if
> no
> changes to the space allocation is made is useful. It won't get the space
> usage but it would save on index thrashing. But that still implies all the
> code to handle scans, updates, index builds, etc. Those chunks could be
> separated out but you can't commit without them.
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-05-03 08:54:26 | Re: Sequential scans |
Previous Message | Heikki Linnakangas | 2007-05-03 08:25:29 | Re: Sequential scans |