Index AM API changes for deferability

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Index AM API changes for deferability
Date: 2009-07-15 05:02:43
Message-ID: 1247634163.13110.90.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I am reviewing the following patch:

http://archives.postgresql.org/message-id/8e2dbb700907071138y4ebe75cw81879aa513cf82a3@mail.gmail.com

In order to provide useful feedback, I would like to reach a consensus
on a possible index AM API change to make it easier to support
deferrable constraints for index access methods that enforce the
constraints themselves.

I am trying to word this question carefully, because there is a lot of
context:
* Dean Rasheed is implementing deferrable unique constraints for BTree
(in the patch linked above)
* Kenneth Marshall has indicated that he would like to implement
unique hash indexes in a way similar to the current btree
implementation:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00812.php
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00834.php
* I have a patch up for review that implements more general
constraints that are enforced outside of AM-specific code, and
therefore do not require index AM changes to support deferrable
constraints:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php

The btree unique code is already a "serious failure of modularity":
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00427.php

So, assuming that we support all of these features together, we have two
options that I see:
1. Extend the index AM API in a manner similar to Dean's patch.
2. Try to come up with some workaround to avoid changing the AM API

I was originally leaning toward approach #2 because I saw btree as the
only index AM that needed it, so extending the API seemed a little
excessive. However, seeing as it's potentially useful for unique hash
indexes, too, I am now leaning toward approach #1.

Also, we don't have performance numbers for either my feature or a
unique constraint implemented inside the hash index AM, so we don't know
whether that's a big win to enforce the constraint in the AM-specific
code or not.

So, should we proceed assuming an index AM API change, or try to avoid
it? If we should change the AM API, is Dean's API change acceptable?

Regards,
Jeff Davis

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2009-07-15 06:06:48 Re: [PATCH 3/3] Document geqo_seed variable.
Previous Message Fujii Masao 2009-07-15 04:32:33 Re: Synch Rep for CommitFest 2009-07