From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] Minmax indexes |
Date: | 2013-06-17 20:31:43 |
Message-ID: | 20130617203143.GA3390@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-06-17 16:23:40 -0400, Alvaro Herrera wrote:
> > > Re-summarization is relatively expensive, because the complete page range has
> > > to be scanned.
> >
> > Why? Why can't we just update the affected pages in the index?
>
> The page range has to be scanned in order to find out the min/max values
> for the indexed columns on the range; and then, with these data, update
> the index.
Why? Assuming the initial summarization has been performed you can check
the current min/max value, check whether it's still smaller/bigger than
the value you're inserting and if not update the index accordingly with
the new value. You don't even need to wait for the new value to become
visible since the ranges don't need to be minimal.
I think the contention this possibly causes may a better argument, but I
am not sure how much of a problem that really becomes if we find a
deadlock free way to only lock the minmax pages exlusively if the range
is violated.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-06-17 20:34:52 | Re: [RFC] Minmax indexes |
Previous Message | Alvaro Herrera | 2013-06-17 20:23:40 | Re: [RFC] Minmax indexes |