Perhaps it is over the top just for my specific query.
Basically, i wish not to do something the system should do
because, as i already noticed, when versions changes the
database can break your code if you don't keep up.
I guess i can make a map of attributes participating in an index
of a relation.
Also, i would have to take into account the type of index used.
For example, a btree should have the capability to do prefix key
searches while hash indices probably can't.
Then check each target tuple if it can use an index.
All this before constructing the query for the planner.
However, i already played with this in the past. I reached
the conclusion that it is better to let the planner decide what is
best since it is too complex for me to say things about cost
estimates or index changing capabilities.
On Friday 23 June 2006 19:28, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Fri, Jun 23, 2006 at 03:57:19PM +0300, Tzahi Fadida wrote:
> >> (SELECT * FROM R
> >> WHERE a=3, b=6,. ...)
> >> UNION
> >> (SELECT * FROM R
> >> WHERE b=5, d=2,. ...)
> >> UNION
> >> ....
> >> And lots of unions.
> >
> > Do you need UNION, or do you actually mean UNION ALL?
> >
> > Also, couldn't you just do:
> >
> > SELECT * FROM R
> > WHERE (a=3, b=6, ...)
> > OR (b=5, d=2, ...)
> > etc
>
> That seems to be what Tzahi wants the system to do for him. But the OR
> format is not in general logically equivalent to either UNION or UNION
> ALL, because UNION would cause duplicate output rows to be suppressed
> whereas UNION ALL could allow the same table row to be emitted multiple
> times (if two different WHERE conditions could select the same row).
>
> It's conceivable that the planner could prove that neither effect is
> possible in a particular query and then make the transformation
> automatically, but I'm not about to expend that kind of planning effort
> on such an odd case --- checking for it would waste entirely too many
> cycles in most cases.
>
> regards, tom lane
--
Regards,
��������Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS: �see at
http://members.lycos.co.uk/my2nis/spamwarning.html