Re: advanced index (descending and table-presorted descending) - Mailing list pgsql-general

From John D. Burger
Subject Re: advanced index (descending and table-presorted descending)
Date
Msg-id 92F0CA73-8372-4CF1-BD10-D724122BE9D4@mitre.org
Whole thread Raw
In response to Re: advanced index (descending and table-presorted descending)  ("Peter Childs" <peterachilds@gmail.com>)
Responses Re: advanced index (descending and table-presorted descending)  ("Jim Nasby" <jim.nasby@enterprisedb.com>)
List pgsql-general
> However, Cluster might work for you, but you need to re-cluster after
> every updates or inserts, so it will probably be fine for static data.

This reminds me of a (somewhat off-topic) question I have had:

I have a static database, and most of the tables are 100% correlated
with one column or another (because I build them that way, or due to
clustering).  In some cases I join two tables on one of these
perfectly correlated columns, and so the planner wants to sort the
two on that column.  Of course, this is unnecessary, and for large
tables, the sorts get spilled to disk (I suppose) and can take a
while.  Is there any way to convince the planner that the sorts are
unnecessary, and it can just zip the two tables together as is?

This is under PG 7.4, by the way.  Any comments welcome.

- John D. Burger
   MITRE


pgsql-general by date:

Previous
From: Francisco Reyes
Date:
Subject: Re: Superuser lost access to particular database
Next
From: Tom Lane
Date:
Subject: Re: Trapping PL/Perl spi_query_exec errors