[Cross post from -SQL]
Hi,
I am trying to model a macro system where I have simple things, and more complex thing consisting of simple things. To do that I have
"invented" this table definition:
CREATE TABLE params
(
param_id serial NOT NULL,
name text NOT NULL,
unit text,
real_param_
Hi Tom,
This sounds like the same "problem" which prevented PG from using the
indices, and thus giving abyssmal performance in this other thread:
I have two BIG tables (virtually identical) with 3 NOT NULL columns
Station_id, TimeObs, Temp_, with unique indexes on (Station_id,
TimeObs) a
the query
optimizer does not push the conditions down into the sub-queries - right??
The reason that I do not just use the reformulated query, is that e.g.
the station_id comes from another table (and there can be more of them),
so it is bloody inconvenient to first select them, and then re
Tom Lane wrote:
Kim Bisgaard <[EMAIL PROTECTED]> writes:
The reason the first query is not performing is because the query
optimizer does not push the conditions down into the sub-queries - right??
Well, it's not the same condition: the WHERE clause is constraining
Try this:
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
Peter L. Berghold wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks,
I remember seeing somewhere a document that outlined how to tune memory
for optimal operation of a postgres server on Linux. I can't seem to
