"Luke Lonergan" <LLonergan(at)greenplum(dot)com> writes:
> I think we do know, have you reviewed the results in the briefing?
I find those results moderately unconvincing, primarily because they
are based on choosing the least efficient possible data representation
(viz char(n)), and thus the btree indexes suffer severe and quite
artificial bloat. A database schema chosen with even minimal attention
to PG-specific tuning would probably have btree indexes half the size.
That wouldn't completely eliminate the performance differential shown,
but it would bring it down into the ballpark where you have to question
whether it makes sense to support another index AM.
The reason I have such high sales resistance is that we've carried the
hash and rtree AMs for years, hoping that someone would do the work to
make them actually worth using, with little result. I don't want any
more second-class-citizen index AMs, and that's why I'm questioning
what the scope of applicability of bitmap indexes really is. They need
to be popular enough that people will be motivated to work on them,
or they shouldn't be in core.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Hiroshi Saito||Date: 2006-07-25 17:12:31|
|Subject: Re: [HACKERS] Patch for VS.Net 2005's strxfrm() bug|
|Previous:||From: Jim Nasby||Date: 2006-07-25 16:57:49|
|Subject: Re: Freezing tuples on pages dirtied by vacuum |