From: Christopher Browne <cbbrowne@acm.org>
Subject: Re: Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables
Date: Tue, 14 Sep 2004 23:33:49 -0400
Organization: cbbrowne Computing Inc
Lines: 27
Message-ID: <m37jqw8aua.fsf@wolfe.cbbrowne.com>
References: <20040914223333.GL56059@decibel.org>
	<NOEFLCFHBPDAFHEIPGBOEEHPCEAA.simon@2ndquadrant.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity,
	linux)
Cancel-Lock: sha1:UaTkqIHblGpHjV0yZ3T3QN7XDVw=
To: pgsql-performance@postgresql.org

simon@2ndquadrant.com ("Simon Riggs") wrote:
> The main point is that the constant placed in front of each table
> must in some way relate to the data, to make it useful in
> querying. If it is just a unique constant, chosen at random, it
> won't do much for partition elimination.

It just struck me - this is much the same notion as that of "cutting
planes" used in Integer Programming.

The approach, there, is that you take a linear program, which can give
fractional results, and throw on as many additional constraints as you
need in order to force the likelihood of particular variable falling
on integer values.  The constraints may appear redundant, but
declaring them allows the answers to be pushed in the right
directions.

In this particular case, the (arguably redundant) constraints let the
query optimizer have criteria for throwing out unnecessary tables.
Thanks for pointing this out; it may turn a fowl into a feature, when
I can get some "round tuits" :-).  That should allow me to turn an
81-way evil join into something that's 4-way at the worst.

Cheers!
-- 
"cbbrowne","@","linuxfinances.info"
http://linuxfinances.info/info/nonrdbms.html
Implementing systems is 95% boredom and 5% sheer terror.