From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: generalized index constraints |
Date: | 2009-07-06 15:57:52 |
Message-ID: | 1246895872.28986.36.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2009-07-06 at 07:30 -0700, David Fetter wrote:
> > It would be useful to see a real example of what this can be used
> > for.
>
> Constraints like "these intervals can't overlap" would be one. It's
> handy in calendaring applications, for example.
Exactly, you already know my use case ;) My goal is a "temporal key",
where you can't have overlapping intervals of time, e.g. the constraint
"nobody can be two places at the same time".
> > I think it will be useful to separate the concepts of a constraint
> > from the concept of an index. It seems possible to have a UNIQUE
> > constraint that doesn't help at all in locating rows, just in
> > proving that the rows are unique.
>
> Interesting idea. Are you thinking of this in terms of things the
> planner can do once it knows a set is all distinct values, or...?
I think that's an orthogonal idea.
It's a good idea though, I would like the planner to be smarter about
those kinds of things. A simple example is that if a table has a
non-partial unique constraint anywhere, then "select * from foo union
select * from foo" can be transformed into "select * from
foo" (eliminating the expensive union).
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-07-06 16:02:27 | Re: WIP: generalized index constraints |
Previous Message | Jeff Davis | 2009-07-06 15:50:17 | Re: WIP: generalized index constraints |