I just saw that there is no where clause in the query, that you had fed to explain plan. you need to include a where clause based on id_machine column to see the effect. On 12/13/05, Pandurangan R S <pandurangan.r.s@xxxxxxxxx> wrote: > Did you set constraint_exclusion = true in postgresql.conf file? > > On 12/13/05, Marc Cousin <mcousin@xxxxxxxx> wrote: > > Hi, > > > > I've been working on trying to partition a big table (I've never partitioned a > > table in any other database till now). > > Everything went ok, except one query that didn't work afterwards. > > > > I've put the partition description, indexes, etc ..., and the explain plan > > attached. > > > > The query is extremely fast without partition (index scan backards on the > > primary key) > > > > The query is : "select * from logs order by id desc limit 100;" > > id is the primary key. > > > > It is indexed on all partitions. > > > > But the explain plan does full table scan on all partitions. > > > > While I think I understand why it is doing this plan right now, is there > > something that could be done to optimize this case ? Or put a warning in the > > docs about this kind of behaviour. I guess normally someone would partition > > to get faster queries :) > > > > Anyway, I thought I should mention this, as it has been quite a surprise. > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > > message can get through to the mailing list cleanly > > > > > > > > > > > -- > Regards > Pandu >
