I started looking at this patch and it looks pretty good as far as it goes. But I think we can do a lot more. It seems to me the cases where foreign key relationships exist are likely to be really big use cases.
I have one big worry though. Currently you're detecting the unique property using the planner's path mechanism. I suppose that works, but it's only an accident of the planner design that the path for the unique index will always be there if it's the join condition. My instinct is that this code should be going back to the raw index info to prove this property. The only practical effect I can think of is that the plan will have to be marked as being dependent on that index and that will be hard to do if you haven't identified a specific index you're basing it on. I would like to see a list of cases we plan to tackle preferably with example queries, as a kind of checklist so we can knock them down one by one. Right now it's unclear just how much of the problem space is being solved. Incidentally, guess what other database just got this feature committed... http://askmonty.org/worklog/Client-BackLog/?tid=17 -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers