"Ilia Kantor" <[EMAIL PROTECTED]> writes:
> Maybe a quickfix is possible for cases when 0 records is found to stop
> reading other AND elements..
Not sure how useful this will be in practice (since the planner tends
not to bother ANDing unselective indexes at all), but it's easy enough
to do ... s
"Ilia Kantor" <[EMAIL PROTECTED]> writes:
> So I just suggest that the planner should take this into account and
> "propagate" the condition outside or inside for planning if needed.
I believe it does this already for equality conditions, but not for
inequalities.
regards,
"Ilia Kantor" <[EMAIL PROTECTED]> writes:
> Looks like GIST indexes for intarray give no statistic at all.
Feel free to contribute some stats routines that aren't stubs ...
regards, tom lane
---(end of broadcast)---
TIP 9: I
I have a query:
SELECT oh.idFROM objects_hier ohwhereoh.id < 2000 (!)andoh.id in ( SELECT id as id FROM objects_access oa WHERE oa.master IN (1,2,10001) AND oa.id < 2000 (!)
)
The sense of the query is simple: I choose ids from
objects_hier where access has
explain analyze select * from objects_hier where tg
&& array[0] and id <1;
Bitmap Heap Scan on objects_hier
(cost=4.79..8.80 rows=1 width=337) (actual time=0.110..0.110 rows=0 loops=1)
Recheck Cond: ((tg &&
'{0}'::integer[]) AND (id < 1))
-> BitmapAnd
(cost=4.79..4.79
I tried to use intarray on 8.1 . It seems to give
same estimates for anything I ask:
explain analyze select * from objects_hier where tg &&
array[10001]
explain analyze select * from objects_hier where tg &&
array[0]
explain analyze select * from objects_hier where tg @
array[10001]
Jeff Trout <[EMAIL PROTECTED]> writes:
> Tracking ti down a bit timestamp_cmp_internal (The btree was made of
> a timestamp & and int) was taking a large amount of time -
> specifically all the calls it makes to isnan(x). 14.1% in __isnand
Hmm, can you provide a test case for other people t
On 27-8-2005 16:27, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
Is a nested loop normally so much (3x) more costly than a hash join? Or
is it just this query that gets estimated wronly?
There's been some discussion that we are overestimating the cost of
nestloops in gene
