| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Process local hint bit cache |
| Date: | 2011-04-03 00:37:57 |
| Message-ID: | 3739.1301791077@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Thu, Mar 31, 2011 at 5:38 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> working on exanding the cache to # xid > 1.
> patch attached. this is essentially my original idea except it's
> injected directly in to tqual.c as a kind of a expansion of the 'last
> seen' concept. Because the cache loops are inlined and very tight (4
> int compares), it's actually cheaper than jumping out of line into
> clog to test this_int = that_int;
This seems like a mess. Why is the criterion for caching commit states
different from whether the hint bit can be set? And why are you
cluttering tqual.c with it? Based on the initial description I'd
expected to find this enlarging the single-entry cache in transam.c
to have multiple entries.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shigeru Hanada | 2011-04-03 01:51:04 | Re: Re: [COMMITTERS] pgsql: Support comments on FOREIGN DATA WRAPPER and SERVER objects. |
| Previous Message | Tom Lane | 2011-04-02 22:50:17 | Re: wal_buffers = -1 and SIGHUP |