post your table definitions. I suspect you are
indexing the parent table but not the children.
btw, we tried using inherited tables in our
application and quickly found out that they are more
trouble then they are worth (at least the way they are
implemented in postgresql). There are other, more
] Failure to use indexes
Greetings!
I managed to get an even simpler example:
select *
from eventlog.record_main
where luid in (
select luid from eventlog_partition._20050706__raw_record
order by luid limit 1
)
;
If I use = rather than in, postgresql uses index scanning. As soon as
I use
: Re: [GENERAL] Failure to use indexes
Greetings!
I managed to get an even simpler example:
select *
from eventlog.record_main
where luid in (
select luid from
eventlog_partition._20050706__raw_record
order by luid limit 1
)
;
If I use = rather than in, postgresql uses
On Tue, 2005-08-02 at 16:06, Dr NoName wrote:
The solution to my problem was to increase statistics
value and do another analyze. You can also change
default_statistics_target parameter in
postgresql.conf. Don't know if that's related to the
problem you're seeing, but it's worth a try.
Cool
Greetings!
I have already increased the stats from 10 to 100. In addition, if I
specify individual tables, then the indexes are used. However, when I go
through the inherits, then indexes are not used. I will try and expand
the statistics, but suspect it is not the root cause of the problem.
Greetings!
I am using inherits to partition several tables. When I perform a query
on another table, and then try to join against an inherited table set, the
optimizer does not use any indexes to perform the join.
This is 8.0.1. Is this fixed in 8.0.2 or 8.0.3?
The query:
explain
select *
from
Greetings!
I managed to get an even simpler example:
select *
from eventlog.record_main
where luid in (
select luid from eventlog_partition._20050706__raw_record
order by luid limit 1
)
;
If I use = rather than in, postgresql uses index scanning. As soon as
I use in (ie, a set to
