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 <[EMAIL PROTECTED]> wrote:
> Did you set constraint_exclusion = true in postgresql.conf file?
>
> On 12/13/05, Marc Cousin <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your
> > message can get through to the mailing list cleanly
> >
> >
> >
> >
>
>
> --
> Regards
> Pandu
>
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
