From: Matthew Wakeling
Subject: Re: B-Heaps
Date: ,
Msg-id: alpine.DEB.2.00.1006151313370.4083@aragorn.flymine.org
(view: Whole thread, Raw)
In response to: B-Heaps  (Eliot Gable)
Responses: Re: B-Heaps  (Robert Haas)
List: pgsql-performance

Tree view

B-Heaps  (Eliot Gable, )
 Re: B-Heaps  (Heikki Linnakangas, )
 Re: B-Heaps  (Greg Smith, )
  Re: B-Heaps  ("A. Kretschmer", )
  Re: B-Heaps  (Yeb Havinga, )
 Re: B-Heaps  (Matthew Wakeling, )
  Re: B-Heaps  (Robert Haas, )
   Re: B-Heaps  (Matthew Wakeling, )
    Re: B-Heaps  (Greg Smith, )
     Re: B-Heaps  (Yeb Havinga, )
      Re: B-Heaps  ("Kevin Grittner", )
       Re: B-Heaps  (Yeb Havinga, )
     Re: B-Heaps  (Tom Lane, )
     Re: B-Heaps  (Robert Haas, )
      Re: B-Heaps  (Greg Smith, )

On Mon, 14 Jun 2010, Eliot Gable wrote:
> Just curious if this would apply to PostgreSQL:
> http://queue.acm.org/detail.cfm?id=1814327

Absolutely, and I said in
http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
but applied to the Postgres B-tree indexes instead of heaps. It's a pretty
obvious performance improvement really - the principle is that when you do
have to fetch a page from a slower medium, you may as well make it count
for a lot.

Lots of research has already been done on this - the paper linked above is
rather behind the times.

However, AFAIK, Postgres has not implemented this in any of its indexing
systems.

Matthew

--
 An ant doesn't have a lot of processing power available to it. I'm not trying
 to be speciesist - I wouldn't want to detract you from such a wonderful
 creature, but, well, there isn't a lot there, is there?
                                        -- Computer Science Lecturer


pgsql-performance by date:

From: Matthew Wakeling
Date:
Subject: Re: B-Heaps
From: Chris Browne
Date:
Subject: Re: PostgreSQL as a local in-memory cache