AW: pg_index.indislossy

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: pg_index.indislossy
Date: 2001-05-15 10:07:32
Message-ID: 11C1E6749A55D411A9670001FA6879633682C6@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > Let's avoid removing things for the sake of removing them ... might be an
> > old idea that, if someone takes the time to research, might prove useful
> > ...
>
> Yea, there is actually some code attached to this vs. the others that
> had no code at all. Are we ever going to do partial indexes? I guess
> that is the question.

The idea is very very good, and since there is an exaple implementation in
pg 4 it should probably be possible to reimplement. (DB2 has this feature also)

In real life, you would e.g. index a status column for rows, that need more work.
create index deposit_status_index on deposit (status) where status <> 0;
99% of your rows would have status = 0 thus the index would be extremely
efficient for all select statements that search for a specific status other than 0.

Imho it would be a shame to give up that idea so easily.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-05-15 10:10:22 AW: pg_index.indislossy
Previous Message Oleg Bartunov 2001-05-15 09:19:29 please apply patch for GiST (7.1.1, current cvs)