Re: Postgres ignoring RTree for geometric operators

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

In response to

Browse pgsql-docs by date

  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