Re: A question for Mr. Celko

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Mon, 19 Jul 2004 00:18:54 GMT
Message-Id: <pan.2004.07.19.00.19.32.644229_at_REMOVETHIS.pandora.be>


On Sun, 18 Jul 2004 16:13:24 +0000, Marshall Spight wrote:
> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> news:pan.2004.07.18.10.12.22.935425_at_REMOVETHIS.pandora.be...

>> On Sun, 18 Jul 2004 00:12:27 +0000, Marshall Spight wrote:
>>
>> So what happens for example if the list is really big and I do a join
>> between the list and the relation in the relation-valued attribute.
>> Will your query optimizer recoginize that situation and choose the
>> right join algorithm?

>
> I'm still unclear on implemenation techniques involving mixing lists and
> relations. (Also, I'm not sure what list you mean; did you mean "*a*
> list" instead of "*the* list"? Is the list an attribute?) Can I rewrite
> your question to use two relation-valued attributes?

Er, no, because then it becomes "Can the optimizer decide when a join between two relations is a join?" which is not really such a difficult question. :-) Let me simplify it for you to the question if in you list algebra the optimzer can recognize exactly when a certain expression actually computes a join.

> The list-as-relation question is a hard one. For most lists, the best
> implementation is an array, but this doesn't make the situation very
> nice when you want to treat the list a relation on (position, element)
> and do queries on it.

That's a physical layer problem and the ideal database should let you choose the right data structure for the mix of updates and queries that you expect. So the question is not "what is the best data structure" but "what data structures are there" and in which case should we use which data structure. And after that you have to tackle the question how you let the query optimizer make use of the data structure that is used when it is confronted with a certain ad hoc query.

  • Jan Hidders
Received on Mon Jul 19 2004 - 02:18:54 CEST

Original text of this message