On Sun, 2004-11-14 at 22:59, Neil Conway wrote:
> On Sun, 2004-11-14 at 11:06 +0000, Simon Riggs wrote:
> > HASH - works OK, but a pain to administer, no huge benefit in using
>
> At least in theory, I think this could offer better performance for
> equality searches than b+-tree. Given how common those kinds of queries
> are, I still think hash indexes are worth putting some time into. My
> guess is that their relatively poor performance at present (relative to
> b+-trees) is just a reflection of how much more tuning and design work
> has gone into the b+-tree code than the hash code.
Can be faster for equality searches on a fairly static table; on a
growing table, could be same or worse. IMHO The theoretical difference
in speed doesn't seem worth the effort of spending additional time in
that part of the code, given the inherent pain of REINDEX.
> > GiST - index of choice for PostGIS, TSearch2, in need of optimization
>
> I'm working on adding page-level locking and WAL safety, although this
> is a pretty difficult project.
Difficult, yes. I'm glad you're stepping up to the plate for the WAL
safety.
Two index types is sufficient, and ISTM should be the maximum therefore.
When you've finished tuning GiST, I wager that you will agree :)
--
Best Regards, Simon Riggs
