From: Kevin Grittner
Subject: Re: B-Heaps
Date: ,
Msg-id: 4C1B783602000025000325CE@gw.wicourts.gov
(view: Whole thread, Raw)
In response to: Re: B-Heaps  (Yeb Havinga)
Responses: Re: B-Heaps  (Yeb Havinga)
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, )

Yeb Havinga <> wrote:

> concerning gist indexes:
>
> 1) with larger block sizes and hence, larger # entries per gist
> page, results in more generic keys of those pages. This in turn
> results in a greater number of hits, when the index is queried, so
> a larger part of the index is scanned. NB this has nothing to do
> with caching / cache sizes; it holds for every IO model. Tests
> performed by me showed performance improvements of over 200%.
> Since then implementing a speedup has been on my 'want to do
> list'.

As I recall, the better performance in your tests was with *smaller*
GiST pages, right?  (The above didn't seem entirely clear on that.)

-Kevin


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