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