Re: Optimization rules for semi and anti joins

From: Gianni Ciolli <gianni(dot)ciolli(at)2ndquadrant(dot)it>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Optimization rules for semi and anti joins
Date: 2009-02-11 13:24:31
Message-ID: 20090211132431.GA3400@eee.gi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On Tue, Feb 10, 2009 at 09:41:46PM +0100, Dimitri Fontaine wrote:
> Hi,
>
> Le 10 févr. 09 à 21:10, Tom Lane a écrit :
>
>> I wrote (in response to Kevin Grittner's recent issues):
>>> Reflecting on this further, I suspect there are also some bugs in the
>>> planner's rules about when semi/antijoins can commute with other
>>> joins;
>>
>> After doing some math I've concluded this is in fact the case. Anyone
>> want to check my work?
>
> I don't know how easy it would be to do, but maybe the Coq formal proof
> management system could help us here:
> http://coq.inria.fr/
>
> The harder part in using coq might well be to specify the problem the
> way you just did, so...

formal theorem proving and mechanized mathematics happen to be one of
my research topics in the last few years; so I think that my
experience could be helpful with such problems.

(Actually instead of Coq I use HOL Light, whereas other people in my
research group work with Coq; but both of them are for the same
purpose)

Perhaps a way to begin would be to start writing a formalization of
the above rules, in order to assess the problem quickly, and then to
get back to pg-hackers soon.

Any comments/warnings/suggestions ?

Thank you,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2009-02-11 13:38:25 Re: Review: B-Tree emulation for GIN
Previous Message Robert Haas 2009-02-11 13:07:34 Re: A deprecation policy