Message-ID: <4EB4AEEC.6050408@ringerc.id.au>
Date: Sat, 05 Nov 2011 11:35:08 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Olgierd Michalak <olgierdm@softcomputer.com>
CC: "pgsql-sql@postgresql.org" <pgsql-sql@postgresql.org>
Subject: Re: How to implement Aggregate Awareness?
References: 
 <F8991549C624E2429C578E86D68A4D027F42A9C9@EXCH-MBX01.softcomputer.com>
In-Reply-To: 
 <F8991549C624E2429C578E86D68A4D027F42A9C9@EXCH-MBX01.softcomputer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/05/2011 05:03 AM, Olgierd Michalak wrote:

> Simply put, when Transparent (to the reporting tool) Aggregate Navigator
> recognizes that a query would execute faster using aggregates, it
> automatically rewrites the query so that the database hits the smaller
> aggregates rather than larger detail tables upon which the small
> aggregates are pre-computed.

Assuming I understand what you want correctly: Before you could usefully 
do anything like that, I think you'd need to implement full support for 
materialized views.

Once that's in place, the optimizer could potentially be enhanced to 
recognise queries against a base table and rewrite it to use a 
materialized view of the table when it sees that the query only touches 
data collected by the materialized view.

Right now, there isn't really anything for query rewriting like this to 
/target/ .

--
Craig Ringer