It's meant for heterogeneous data sources and, as you put it,
scheme graph where you want to take out information you did not
initially design for. It is not unheard of to have a cycle in your
scheme graph, in which case Full disjunction is the only way to pull
out all the information with no subsumptions, duplications, loss of information,
dealing with nulls.
In addition, heterogeneous data source that are found abundantly on the web.
For example, xmls, etc they are on your database, you have to do something
with them. Most commonly they don't play nice with an ideal design.
Not to mention, the classic outside entity that your organization now wants to interface without
redisigning the whole database.
Here is a simple use case:
http://www.technion.ac.il/~tzahi/soc.html
In the example you can see the level of information with FD and with natural outer joins.
P.s.: The proposal is to put this in the contrib. I already have a working and stable
prototype which if the project will be selected, i plan to enhance so it can be used
by anyone.
Regards,
tzahi.
Message
From: pgsql-general-owner (AT) postgresql (DOT) org
[mailto:pgsql-general-owner (AT) postgresql (DOT) org] Behalf Tom Lane
Sent: Saturday, May 06, 2006 12:26 AM
To: Tzahi Fadida
Cc: pgsql-general (AT) postgresql (DOT) org
Subject: Re: [GENERAL] Google Summer of Code: Full Disjunctions
"Tzahi Fadida" <tzahi_ml (AT) myrealbox (DOT) comwrites:
The output of the full disjunctions FD(A,B,C):
FD
X Y Z
a | b | c
a | b | d
This output cannot be generated using standard SQL statements.
Does anybody care? Your example looks to me like nothing but a poorly
designed schema. You should show a more compelling use-case
if you want
people to take an interest.
regards, tom lane
(end of
broadcast)
TIP 6: explain analyze is your friend
(end of broadcast)
TIP 5: don't forget to increase your free space map settings

First, i have no knowledge of anyone that have implemented full disjunctions(ever) aside
from the theoretical works of my colleagues.
With the exception of a corner case of it, that I believe was a simulation in 96.
(A. Rajaman and J.D. Ullman Integrating information by outerjoins and full-disjunctions).
I'd love to hear about any implementation out there (aside from my colleagues work, which
is mine also: cohen,sagiv, kimelfeld,kanza)

I didn't mean to imply there was. It was the Rajaraman & Ullman paper
that got me interested in FD's and then I've looked at the "Computing
Full Disjunctions" paper by Kanza & Sagiv which gives a general
solution.
from the second paper it's clear that implementing full
disjunction (efficiently) is a non-trivial exercise.

It can never be a binary operation since at the heart of the matter is that you need to take
each subset of the relations and join them. i.e.:

Usually binary operations allow for a bottom up computation approach, but FD is a TP down approach
(Galindo-Legaria, C. outerjoins as disjunctions).

Right, thanks for clarifying.

>From a data analysis perspective I would like to be able to look at
various subsets, eg. FD(A,B,C), FD(B,C,D), FD(A,B,C,D) etc and so this
just means that each subset has too be computed independantly. I can
live with that but wasn't sure if I had missed something.

In any case, the difficulty of implementing FD precludes me from
experimenting with it just yet.

Regards
Lee

(end of broadcast)
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match