On Tue, Sep 26, 2006 at 12:35:54PM +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> >>We could rename pg_attribute as pg_userattribute, and remove all the
> >>system attributes from that. To stay backwards-compatible, we could have
> >>a pg_attribute view on top of that contained the system a
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If we're going to fool with these, I'd like to renew the suggestion I
>> made awhile back that none of the system columns should have explicit
>> entries in pg_attribute, but rather their lookup should be special-cased
>> in the pa
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries in pg_attribu
Tom Lane wrote:
We could rename pg_attribute as pg_userattribute, and remove all the
system attributes from that. To stay backwards-compatible, we could have
a pg_attribute view on top of that contained the system attributes as well.
I don't really think this is necessary. How many clien
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries in pg_attribute, but rather the
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> We could also limit the size of the hash table, which takes up most of
> the memory, and only keep the latest phantom cids there. Presumably, if
> current command id is 1000, you're not likely to set cmax to 500 on any
> tuple in that transaction
Another question is, what should cmin and cmax system columns return? If
we overlay cmin and cmax, cmin and cmax on-disk will always be the same
value. And with phantom cids, it wouldn't be meaningful outside the
inserting/deleting transaction.
The options that I can think of are:
1. Only ret
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A big question is, do we need to implement spilling to disk?
My thought is no, at least not in the first cut ... this is something
that can be added later if it proves critical, and right at the moment
my guess is that it n
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I didn't realize we had a lot of ways a backend could run a machine out
> of memory, or at least ways that didn't have some kind of limit (ie:
> work_mem). Are any of them very easy to run into?
work_mem has nothing to do with trying to guarantee "no sw
On Wed, Sep 20, 2006 at 04:22:47PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > What would the failure mode be? Would we just keep going until the box
> > ran out of memory? I think it'd be better to have some kind of hard
> > limit so that a single backend can't grind a
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What would the failure mode be? Would we just keep going until the box
> ran out of memory? I think it'd be better to have some kind of hard
> limit so that a single backend can't grind a production server into a
> swap-storm. (Arguably, not having a lim
On Wed, Sep 20, 2006 at 04:02:00PM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > A big question is, do we need to implement spilling to disk?
>
> My thought is no, at least not in the first cut ... this is something
> that can be added later if it proves critical, and
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> A big question is, do we need to implement spilling to disk?
My thought is no, at least not in the first cut ... this is something
that can be added later if it proves critical, and right at the moment
my guess is that it never will. The data struc
Per discussion on reducing heap tuple header, I've started to work on
the phantom cid idea.
I'm thinking of having an array of cmin,cmax pairs, indexed by phantom
cid number. Looking up cmin,cmax of a phantom id is then a simple array
lookup. To allow reusing phantom cids, we have a hash table
14 matches
Mail list logo
