Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Frankly the whole phantom commandid thing sounds more complicated. You
> > *still*
> > need a local state data structure that *still* has to spill to disk and now
> > it's much harder to characterize how large it will grow since it de
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane kirjoitti:
>> I'm also concerned about loss of debug traceability if these fields
>> disappear entirely from disk --- it's been handy more than once to be
>> able to tell where in a complex transaction something happened.
> Sure. We'll just
Tom Lane kirjoitti:
I'm also concerned about loss of debug traceability if these fields
disappear entirely from disk --- it's been handy more than once to be
able to tell where in a complex transaction something happened.
Sure. We'll just have to try to compensate that with debug messages
e
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> As I tried to say in the first post, I believe we can actually get away
> without an entry in local memory in typical scenarios, including bulk
> data loads.
I didn't find that argument very credible, particularly not the part
that assumes we know
Tom Lane kirjoitti:
Gregory Stark <[EMAIL PROTECTED]> writes:
Frankly the whole phantom commandid thing sounds more complicated.
You *still*
need a local state data structure that *still* has to spill to disk
and now
it's much harder to characterize how large it will grow since it
depends on
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well there's a reason we support commandids up to 4 billion. One of the common
> use cases of bulk loading data in a series of individual inserts would cause
> such a structure to spill to disk. As would ISAM style programming that steps
> through a large
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Frankly the whole phantom commandid thing sounds more complicated. You
>> *still*
>> need a local state data structure that *still* has to spill to disk and now
>> it's much harder to characterize how large it wil
Gregory Stark <[EMAIL PROTECTED]> writes:
> Frankly the whole phantom commandid thing sounds more complicated. You *still*
> need a local state data structure that *still* has to spill to disk and now
> it's much harder to characterize how large it will grow since it depends on
> arbitrary combinat
Tom Lane <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
>> bytes (assuming we get rid of xvac in the future, or overlay it with
>> xmin for example) is even better.
>
> xvac is not going away, s
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
> bytes (assuming we get rid of xvac in the future, or overlay it with
> xmin for example) is even better.
xvac is not going away, so that argument is unconvincing, and I don't
be
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm thinking of removing cmin and cmax, and keeping that information in
backend-private memory instead.
I don't believe you can remove *both*. What's been discussed is
removing one of them, by letting the field represent a
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm thinking of removing cmin and cmax, and keeping that information in
> backend-private memory instead.
I don't believe you can remove *both*. What's been discussed is
removing one of them, by letting the field represent a lookup key for an
in-m
We currently use 4 int32s to store xmin, xmax, cmin, cmax and xvac on
every heap tuple. That's a lot of overhead, especially on tables with
narrow rows. Reduction in header size would give us considerable space
and I/O savings.
I'm thinking of removing cmin and cmax, and keeping that informati
13 matches
Mail list logo
