From: | "Gilles Bernard" <gbernard(at)matra-ms2i(dot)fr> |
---|---|
To: | "Ralf Mattes" <rm(at)mh-freiburg(dot)de>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: Postgres ignoring RTree for geometric operators |
Date: | 2001-01-03 15:09:35 |
Message-ID: | 200101031611.RAA08454@fwm1.matra-ms2i.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
I tryed all you suggested me : (forme && '((...))'), drop the index and
recreate it and do a vacuum analyze and it
still do a sequential scan on the whole table.
> Ralf Mattes <rm(at)mh-freiburg(dot)de> writes:
> > Still, the remarkl about running 'vacuum' after the creation
> > of an index seems valid. I was bitten by this just last week--
> > somehow it seems counterintuitive to have to vacuum a table only
> > to tell the system that an index exists. This should be the job
> > of 'create index' or am i wrong?
>
> The system knows perfectly well that the index exists. The issue
> is whether the planner will conclude that the index is worth using
> for a particular query, in the absence of complete statistical
> information. If you've never done a 'vacuum analyze' on the table
> then the planner is flying blind about what to do (and no, it does
> not matter whether the index exists at the time the vacuum is done).
>
> There are some subtle interactions between the default estimates that
> are made for various parameters. The current behavior clearly needs
> work, but I'm hesitant to "fix" it by just lowering the default
> selectivity estimate (or some such) without careful study.
>
> I'm hoping to have some time to spend on that issue for 7.2 ...
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-03 16:24:46 | Re: Postgres ignoring RTree for geometric operators |
Previous Message | Vince Vielhaber | 2001-01-03 13:05:38 | Re: Re: RE: Re: MySQL and PostgreSQL speed compare |