On Wed, Oct 19, 2016 at 9:21 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > The main problem IMV is GIN indexes. It's relatively easy to discuss > variable length PKs with btrees, but the GIN format is designed around > use of 6byte values, so expanding beyond that would require > significant redesign/reimplementation. That would be at least a year's > work for not much benefit, so cannot occur for the first release.
That doesn't bother me. We can add an amcanindirect flag or similar. >> The whole point of an indirect index is that it >> doesn't disable HOT, and the physical location within the index page >> you stick the PK value doesn't have any impact on whether that's safe. > > Agreed, though it does have an impact on the length of the index tuple > and thus the size and effectiveness of the index. > > Perhaps its best to see the restriction to 6byte PKs as both the first > phase of implementation and an optimization, rather than an ugly wart. Perhaps, but I'm not ready to rule out "ugly wart". -- 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
