Re: Proposal: GiST constraints

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: GiST constraints
Date: 2008-06-10 16:46:37
Message-ID: 1213116397.24243.32.camel@dogma.ljc.laika.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2008-06-10 at 16:59 +0400, Teodor Sigaev wrote:
> > This can be solved by my proposal, but I just don't know how it would
> > apply to something like GIN, for instance. It could replace the unique
> Hmm, your proposal isn't applicable to GIN, because GIN stores a lot of keys for
> only one value to be indexed.

Right. I can't think of a good reason to constrain a GIN index, but I
think it is possible using this scheme.

> > being inserted by other concurrent transactions, and those values can
> > be variable in size. What other mechanism do we have to share those
> > variable-sized values among several backends?
> In theory, any indexed value in index (for GiST, after compression) should fit
> into page at least.
>

So are you saying we should dedicate one page multiplied by
max_connections in shared memory? It's possible to do it that way, but
we still have to check the heap for visibility information, at least.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2008-06-10 16:49:17 Re: Overhauling GUCS
Previous Message Josh Berkus 2008-06-10 16:37:37 Re: Overhauling GUCS