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