Skip site navigation (1) Skip section navigation (2)

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
Message-ID: alpine.DEB.1.10.0906041702320.4147@aragorn.flymine.org (view raw or flat)
Thread:
Lists: pgsql-performance
Revisiting the thread a month back or so, I'm still investigating 
performance problems with GiST indexes in Postgres.

Looking at http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items 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 
http://archives.postgresql.org/pgsql-performance/2009-04/msg00276.php 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.

Matthew

-- 
 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.

Responses

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group