From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ralf Mattes <rm@mh-freiburg.de>
Cc: Gilles Bernard <gbernard@matra-ms2i.fr>
Cc: pgsql-docs@postgresql.org
Subject: Re: Postgres ignoring RTree for geometric operators
Date: Mon, 01 Jan 2001 13:50:37 -0500
Message-ID: <23227.978375037@sss.pgh.pa.us> (raw)
In-Reply-To: <20010101145354.A8897@forte.mh-freiburg.de>
References: <200012290946.KAA01221@fwm1.matra-ms2i.fr>
<14474.978302554@sss.pgh.pa.us>
<20010101145354.A8897@forte.mh-freiburg.de>
Ralf Mattes <rm@mh-freiburg.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: tgl@sss.pgh.pa.us, rm@mh-freiburg.de, gbernard@matra-ms2i.fr
Subject: Re: Postgres ignoring RTree for geometric operators
In-Reply-To: <23227.978375037@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox