On Mon, Aug 8, 2016 at 03:36:12PM -0300, Claudio Freire wrote: > I think I prefer a more thorough approach. > > Increment/decrement may get very complicated with custom opclasses, > for instance. A column-change bitmap won't know how to handle > funcional indexes, etc.
Hot does HOT handle them? If it does, it has to look at all the columns passes to the expression index, so it seems to be the same amount of work. > What I intend to try, is modify btree to allow efficient search of a > key-ctid pair, by adding the ctid to the sort order. Only inner pages > need to be changed, to include the ctid in the pointers, leaf pages > already have the ctid there, so they don't need any kind of change. A > bit in the metapage could indicate whether it's a new format or an old > one, and yes, only new indices will be able to use WARM. > > But with efficient key-ctid searches, you handle all cases, and not > just a few common ones. True. I am worried about page spills caused by having to insert a rows into an existing page and and index entry having to be pushed to an adjacent page to maintain ctid index order. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
