Re: Minmax indexes
От | Simon Riggs |
---|---|
Тема | Re: Minmax indexes |
Дата | |
Msg-id | CA+U5nMKWBwoM+ojOWja2nA4i_rcv-fXg444ivSPzrUD04oaRtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Minmax indexes (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On 10 July 2014 00:13, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Josh Berkus wrote: >> On 07/09/2014 02:16 PM, Alvaro Herrera wrote: >> > The way it works now, each opclass needs to have three support >> > procedures; I've called them getOpers, maybeUpdateValues, and compare. >> > (I realize these names are pretty bad, and will be changing them.) >> >> I kind of like "maybeUpdateValues". Very ... NoSQL-ish. "Maybe update >> the values, maybe not." ;-) > > :-) Well, that's exactly what happens. If we insert a new tuple into > the table, and the existing summarizing tuple (to use Peter's term) > already covers it, then we don't need to update the index tuple at all. > What this name doesn't say is what values are to be maybe-updated. There are lots of functions that maybe-do-things, that's just modular programming. Not sure we need to prefix things with maybe to explain that, otherwise we'd have maybeXXX everywhere. More descriptive name would be MaintainIndexBounds() or similar. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: