Re: [RFC] Minmax indexes

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [RFC] Minmax indexes
Дата
Msg-id 20130624235125.GA14698@momjian.us
обсуждение исходный текст
Ответ на Re: [RFC] Minmax indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [RFC] Minmax indexes  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Sat, Jun 15, 2013 at 11:39:23AM -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On 15 June 2013 00:01, Josh Berkus <josh@agliodbs.com> wrote:
> >> If we're going to start adding reloptions for specific table behavior,
> >> I'd rather think of all of the optimizations we might have for a
> >> prospective "append-only table" and bundle those, rather than tying it
> >> to whether a certain index exists or not.
> 
> > I agree that the FSM behaviour shouldn't be linked to index existence.
> > IMHO that should be a separate table parameter, WITH (fsm_mode = append)
> > Index only scans would also benefit from that.
> 
> -1 ... I cannot believe that such a parameter would ever get turned on
> in production by anyone.  If your table has a significant update rate,
> the resulting table bloat would make such behavior completely
> infeasible.  If you have few enough updates to make such a behavior
> practical, then you can live with the expensive index updates instead.

Can you have pages that are receiving updates _not_ track min/max, until
the page is nearly full?  This would require full scans of such pages,
but there might be few of them.  The amount of free spaces on the page
as reported by FSM might be useful here.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: Bugfix and new feature for PGXS
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: C++ compiler