From: Tom Lane
Subject: Re: B-Heaps
Date: ,
Msg-id: 17236.1276890065@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: B-Heaps  (Greg Smith)
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, )

Greg Smith <> writes:
> Your characterization of the potential speed up here is "Using a proper tree
> inside the index page would improve the CPU usage of the index lookups",
> which seems quite reasonable.  Regardless, when I consider "is that
> something I have any reason to suspect is a bottleneck on common
> workloads?", I don't think of any, and return to working on one of
> things I already know is instead.

Note also that this doesn't do a thing for b-tree indexes, which already
have an intelligent within-page structure.  So that instantly makes it
not a mainstream issue.  Perhaps somebody will be motivated to work on
it, but most of us are chasing other things.

            regards, tom lane


pgsql-performance by date:

From: Josh Berkus
Date:
Subject: Re: PostgreSQL as a local in-memory cache
From: Scott Carey
Date:
Subject: Re: requested shared memory size overflows size_t