On Sat, Feb 25, 2017 at 10:50 AM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > On Fri, Feb 24, 2017 at 9:47 PM, Robert Haas <robertmh...@gmail.com> wrote: >> And there are no bugs, right? :-) > > Yeah yeah absolutely nothing. Just like any other feature committed to > Postgres so far ;-)
Fair point, but I've already said why I think the stakes for this particular feature are pretty high. > I need to polish the chain conversion patch a bit and also add missing > support for redo, hash indexes etc. Support for hash indexes will need > overloading of ip_posid bits in the index tuple (since there are no free > bits left in hash tuples). I plan to work on that next and submit a fully > functional patch, hopefully before the commit-fest starts. > > (I have mentioned the idea of overloading ip_posid bits a few times now and > haven't heard any objection so far. Well, that could either mean that nobody > has read those emails seriously or there is general acceptance to that > idea.. I am assuming latter :-)) I'm not sure about that. I'm not really sure I have an opinion on that yet, without seeing the patch. The discussion upthread was a bit vague: "One idea is to free up 3 bits from ip_posid knowing that OffsetNumber can never really need more than 13 bits with the other constraints in place." Not sure exactly what "the other constraints" are, exactly. /me goes off, tries to figure it out. If I'm reading the definition of MaxIndexTuplesPerPage correctly, it thinks that the minimum number of bytes per index tuple is at least 16: I think sizeof(IndexTupleData) will be 8, so when you add 1 and MAXALIGN, you get to 12, and then ItemIdData is another 4. So an 8k page (2^13 bits) could have, on a platform with MAXIMUM_ALIGNOF == 4, as many as 2^9 tuples. To store more than 2^13 tuples, we'd need a block size > 128k, but it seems 32k is the most we support. So that seems OK, if I haven't gotten confused about the logic. I suppose the only other point of concern about stealing some bits there is that it might make some operations a little more expensive, because they've got to start masking out the high bits. But that's *probably* negligible. -- 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
