On Fri, Jun 23, 2006 at 08:14:07PM +0300, Tzahi Fadida wrote:
> 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 has
Tom Lane <[EMAIL PROTECTED]> writes:
> 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 w
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 relati
Martijn van Oosterhout 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
On Fri, Jun 23, 2006 at 06:10:33PM +0300, Tzahi Fadida wrote:
> On Friday 23 June 2006 17:47, Martijn van Oosterhout wrote:
> > On Fri, Jun 23, 2006 at 05:12:14PM +0300, Tzahi Fadida wrote:
> > > My initial reasoning was to avoid extra sorts but i guess that the
> > > planner just doesn't get the L
On Friday 23 June 2006 17:47, Martijn van Oosterhout wrote:
> On Fri, Jun 23, 2006 at 05:12:14PM +0300, Tzahi Fadida wrote:
> > My initial reasoning was to avoid extra sorts but i guess that the
> > planner just doesn't get the LIMIT 1. I see now that UNION should be
> > better for the planner to u
On Fri, Jun 23, 2006 at 05:12:14PM +0300, Tzahi Fadida wrote:
> My initial reasoning was to avoid extra sorts but i guess that the planner
> just doesn't get the LIMIT 1. I see now that UNION should be better
> for the planner to undestand (not performance wise).
> However, UNION alone, doesn't
On Friday 23 June 2006 16:14, Martijn van Oosterhout wrote:
> On Fri, Jun 23, 2006 at 03:57:19PM +0300, Tzahi Fadida wrote:
> > R contains indices but not on all attributes or not on
> > all ordered subset of keys.
> >
> > Query example:
> > (SELECT * FROM R
> > WHERE a=3, b=6,. ...)
> > UNION
> >
On Fri, Jun 23, 2006 at 03:57:19PM +0300, Tzahi Fadida wrote:
> R contains indices but not on all attributes or not on
> all ordered subset of keys.
>
> Query example:
> (SELECT * FROM R
> WHERE a=3, b=6,. ...)
> UNION
> (SELECT * FROM R
> WHERE b=5, d=2,. ...)
> UNION
>
> And lots of unions
Hi,
I think there is a bug/misscalculation of some rare query i am using.
Suppose we only query one specific relation R.
R contains indices but not on all attributes or not on
all ordered subset of keys.
Query example:
(SELECT * FROM R
WHERE a=3, b=6,. ...)
UNION
(SELECT * FROM R
WHERE b=5, d=2
10 matches
Mail list logo