On 10/01/2014 02:42 PM, Simon Riggs wrote:
On 1 October 2014 11:58, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:
On 10/01/2014 01:50 PM, Simon Riggs wrote:
On 1 October 2014 10:44, Heikki Linnakangas <hlinnakan...@vmware.com>
wrote:
I didn't realize that "promise index tuples" were even seriously
discussed.
I guess that can be made to work, too, although I don't see the point. It
wouldn't work with GiST indexes, for the same reasons as page-level
locking
won't work (a tuple can legally be inserted anywhere in a GiST index - it
just degrades the index making searching more expensive). And lossy GiST
opclasses are a problem too.
GiST doesn't support unique indexes, so it is not in any way a problem.
GiST supports exclusion constraints. That is one of the main reasons I want
to do promise tuples, instead of locking within the indexam: to support this
feature with exclusion constraints.
That does sound interesting, but I am concerned the semantics may cause issues.
If I go to insert a row for 'UK' and find an existing row for
'Europe', do we really want to update the population of Europe to be
the population of the UK, simply because the UK and Europe have an
exclusion conflict?
Clearly not, but you might want to insert the tuple to another table
instead, or skip it altogether. Or you might want to UPDATE Europe into
Continental Europe, and then insert the row for UK.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
