On Fri, Oct 21, 2016 at 7:04 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> So, I think that this is a really promising direction, but also that >> you should try very hard to try to get out from under this 6-byte PK >> limitation. That seems really ugly, and in practice it probably means >> your PK is probably going to be limited to int4, which is kind of sad >> since it leaves people using int8 or text PKs out in the cold. > > I think we could just add a new type, unsigned 6 byte int, specifically > for this purpose. Little in the way of operators, as it's pointless to > try to do arithmetic with object identifiers. (It'd be similar to UUID > in spirit, but I wouldn't try to do anything too smart to generate them.)
Sure, we could do that, but that's just band-aiding over the fact that the index page format isn't really what we want for a feature of this type. > Yes, recheck is always needed. > > As for vacuum, I was thinking this morning that perhaps the answer to > that is just to not vacuum the index at all and instead rely on the > killtuple interface (which removes tuples during scan). So we don't > need to spend precious maint_work_mem space on a large list of PK > values. I don't think that's going to fly. Even if it's the case that indirect indexes typically need less cleanup than regular indexes, the idea that there's no command to force a full cleanup short of REINDEX doesn't sit well with me. It's not difficult to construct realistic scenarios in which kill_prior_tuple is almost useless (e.g. values are all marching forward). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
