From: Hannu Krosing <hannu@skype.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Luke Lonergan <LLonergan@greenplum.com>
Cc: mark@mark.mielke.cc, Bruce Momjian <bruce@momjian.us>
Cc: Jie Zhang <jzhang@greenplum.com>
Cc: Gavin Sherry <swm@linuxworld.com.au>
Cc: pgsql-hackers@postgresql.org
Subject: Re: On-disk bitmap index patch
Date: Tue, 25 Jul 2006 21:36:13 +0300
Message-ID: <1153852574.2924.15.camel@localhost.localdomain> (raw)
In-Reply-To: <17917.1153847188@sss.pgh.pa.us>
References: <3E37B936B592014B978C4415F90D662D01F73ACF@MI8NYCMAIL06.Mi8.com>
<17917.1153847188@sss.pgh.pa.us>
Ühel kenal päeval, T, 2006-07-25 kell 13:06, kirjutas Tom Lane:
> "Luke Lonergan" <LLonergan@greenplum.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.
hmm, maybe this should be fixed in btree then ?
do we really need to store padding blanks in btree ?
> 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.
It still depends on your data volumes. if you spend lots and lots of $
on hardware just to store surplus index bloat, it may be worth it.
Remember, that the bizgres folks develop these things for real-world
datawarehousing, where saving a few (tens or hundreds of) terabytes of
storage and corresponging amount of RAM is a real win.
> 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.
What would be the use-case for hash indexes ? And what should be done to
make them faster than btree ? I know that they are not wal-logged, but
this is beside the point for DWH apps.
and was'nt the rtree index recently deprecated in favour of GIST
implementation of the same ?
> 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.
Is there an easy way to put them into contrib/ for some test period so
that they can become popular among mainstream postgresql users ?
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hannu@skype.net, tgl@sss.pgh.pa.us, LLonergan@greenplum.com, bruce@momjian.us, jzhang@greenplum.com, swm@linuxworld.com.au
Subject: Re: On-disk bitmap index patch
In-Reply-To: <1153852574.2924.15.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox