От: Tom Lane
Тема: Re: B-Heaps
Дата: ,
Msg-id: 17236.1276890065@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: B-Heaps  (Greg Smith)
Список: pgsql-performance

Скрыть дерево обсуждения

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 по дате сообщения:

От: Josh Berkus
Дата:
Сообщение: Re: PostgreSQL as a local in-memory cache
От: Scott Carey
Дата:
Сообщение: Re: requested shared memory size overflows size_t