From: | Ralf Mattes <rm(at)mh-freiburg(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gilles Bernard <gbernard(at)matra-ms2i(dot)fr>, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: Postgres ignoring RTree for geometric operators |
Date: | 2001-01-01 13:53:54 |
Message-ID: | 20010101145354.A8897@forte.mh-freiburg.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Sun, Dec 31, 2000 at 05:42:34PM -0500, Tom Lane wrote:
[..]
> Var on the left is the required normal form for indexscan restriction
> clauses. Postgres should be able to figure out that it can flip your
> clause as given into that form ... but for some reason, && is not marked
> as commutative in the 7.0 system catalogs, so it won't do it for you.
>
> I have fixed that for 7.1. If you really want to write the var on the
> right side right now, you could patch your system catalogs for yourself:
>
> UPDATE pg_operator SET oprcom = oid WHERE oprname = '&&'
>
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?
Ralf Mattes
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-01 18:50:37 | Re: Postgres ignoring RTree for geometric operators |
Previous Message | Chih-Chang Hsieh | 2001-01-01 12:32:48 | Re: [HACKERS] About PQsetClientEncoding(),"SET NAMES",and "SET CLIENT_ENCODING" |