From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, List pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Hint Bits and Write I/O |
Date: | 2008-07-22 12:44:33 |
Message-ID: | 1216730673.3894.308.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Mon, 2008-07-21 at 16:33 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Mon, 2008-07-21 at 11:36 +0530, Pavan Deolasee wrote:
> >> I think we should try at least one or two possible optimizations and
> >> get some numbers before we jump and make substantial changes to the
> >> code.
>
> > You know you're suggesting months of tests and further discussion. :-(
>
> I agree with Pavan that we should have something that'd at least serve
> as test scaffolding to verify that the framework patch is sane. The
> test code needn't be anything we'd want to commit.
The test code is/was there, in the sense that the patch was (supposed
to) do exactly what it does now, just with extra code to keep track of
hint counts.
Probably the most important point is not yet covered: we don't keep any
track of which blocks are dirtied solely for hint bits. We need to do
this so we can measure the efficacy of *any* patch that seeks to improve
the current situation.
The best time to do this is in integration phase of release, so will do
it then.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-07-22 13:39:40 | Re: Do we really want to migrate plproxy and citext into PG core distribution? |
Previous Message | Markus Wanner | 2008-07-22 12:43:33 | Re: Postgres-R: primary key patches |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-22 16:03:25 | Re: [PATCHES] GIN improvements |
Previous Message | Simon Riggs | 2008-07-22 06:35:30 | Re: pg_dump additional options for performance |