Re: partitioning
От | Pandurangan R S |
---|---|
Тема | Re: partitioning |
Дата | |
Msg-id | 5e744e3d0512130350l12d136abx2ad661c6d6b6a21e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: partitioning (Pandurangan R S <pandurangan.r.s@gmail.com>) |
Ответы |
Re: partitioning
|
Список | pgsql-performance |
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@gmail.com> wrote: > Did you set constraint_exclusion = true in postgresql.conf file? > > On 12/13/05, Marc Cousin <mcousin@sigma.fr> 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@postgresql.org so that your > > message can get through to the mailing list cleanly > > > > > > > > > > > -- > Regards > Pandu >
В списке pgsql-performance по дате отправления: