On Thu, 2007-08-02 at 16:12 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
> > Alvaro Herrera wrote:
> >> At this
> >> point I feel like the patch still needs some work and reshuffling before
> >> it is in an acceptable state. The fact that there are some API changes
> >> for which the patch needs to be adjusted makes me feel like we should
> >> put this patch on hold for 8.4. So we would first get the API changes
> >> discussed and done and then adapt this patch to them.
>
> > I hate to say it but I agree.
>
> I concur with putting this whole area off till 8.4. We do not have any
> consensus on what the API should be, which is exactly why the patch was
> never finished. All the proposals are pretty ugly.
Given that about 40% of the remaining patch queue is GIT plus other
related stuff, I would now agree and encourage others to as well.
The benefits of bitmap and GIT indexes are high and many people will
benefit if we make them available now. Poor long-term design of code is
an important issue, but some people may not wish to wait.
I would like to suggest that we open up the field a little more. Adding
index types could be just as easy as adding datatypes. We have 2 index
types under discussion here (GIT and bitmap) and another hacker working
on a new form of R-Tree also.
How hard will it be to add the infrastructure to allow new index types
to be added to the server dynamically? Many aspects are already there,
ISTM. We would gain potential access to the new index types, gain an
important extension capability and it will still result in an earlier
release of 8.3.
This will then allow development of those index types to occur on
pgfoundry. We can then fold back in the winners in the race to provide
useful additional indexing capabilities. We may be surprised at the
number of different alternatives people come forward with.
Heck, I'd much rather have bitmap and/or GIT than hash indexes any day.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
