GiST index performance

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: GiST index performance
Date: 2009-06-04 16:33:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

Revisiting the thread a month back or so, I'm still investigating
performance problems with GiST indexes in Postgres.

Looking at I'd
like to clarify the contrib/seg issue. Contrib/seg is vulnerable to
pathological behaviour which is fixed by my second patch, which can be
viewed as complete. Contrib/cube, being multi-dimensional, is not affected
to any significant degree, so should not need alteration.

A second quite distinct issue is the general performance of GiST indexes
which is also mentioned in the old thread linked from Open Items. For
that, we have a test case at for
btree_gist indexes. I have a similar example with the bioseg GiST index. I
have completely reimplemented the same algorithms in Java for algorithm
investigation and instrumentation purposes, and it runs about a hundred
times faster than in Postgres. I think this is a problem, and I'm willing
to do some investigation to try and solve it.

Do you have a recommendation for how to go about profiling Postgres, what
profiler to use, etc? I'm running on Debian Linux x86_64.


Jadzia: Don't forget the 34th rule of acquisition: Peace is good for business.
Quark: That's the 35th.
Jadzia: Oh yes, that's right. What's the 34th again?
Quark: War is good for business. It's easy to get them mixed up.


Browse pgsql-performance by date

  From Date Subject
Next Message Scott Carey 2009-06-04 17:34:23 Re: degenerate performance on one server of 3
Previous Message Craig James 2009-06-04 16:04:12 Re: Query plan issues - volatile tables