From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: A little COPY speedup |
Date: | 2007-03-01 21:05:33 |
Message-ID: | 45E7401D.3040702@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> As you say, pd_tli is not really pulling its weight, but I'm also loath
> to remove it, as in a multi-timeline situation the page LSN is really
> not well defined if you don't know which timeline it refers to.
>
> Now we'd only need 16 bits to store the last-used offset, or a flags
> field if you'd prefer that, so one possible compromise is to store only
> the 16 least significant bits of TLI (which ought to be enough to
> disambiguate in any real-world situation), and insert the new field
> where the MSBs had been.
Sounds good to me. It's nice to keep the TLI for debugging/forensics
purposes even if it's not used at the moment, but 16 bits is enough for
that.
Another possibility would be to use the unused bits in
pd_upper/lower/special, but that requires more bit-trickery.
> I'm not sure whether I like your flag approach better than the
> last-used-offset one. The previous patch probably buys some teeny
> amount more performance, but the flag seems more robust (noting in
> passing that neither patch attempts to WAL-log its changes, so we really
> need to treat the values as hints). And a change as sketched here would
> leave us 15 free bits for future expansion, which might be nice.
I'll post a patch along those lines.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joey Wang | 2007-03-01 21:48:34 | BUG #3095: LDAP authentication parsing incorrectly |
Previous Message | Tom Lane | 2007-03-01 20:30:20 | Re: A little COPY speedup |