Re: Improving planner's handling of min/max aggregate optimization - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Improving planner's handling of min/max aggregate optimization
Date
Msg-id AANLkTi=CnfyTnTTNhXJNGrKuV7fBs+7=S8jAmhjLFdu4@mail.gmail.com
Whole thread Raw
In response to Improving planner's handling of min/max aggregate optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Nov 1, 2010 at 8:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This will make the min/max optimization code more visible to the rest of
> the planner in a couple of ways: aside from being called at two places
> not one, it will have some intermediate state that'll have to be kept in
> PlannerInfo, and the "useful pathkeys" logic will have to be complicit
> in letting paths that match the aggregates' requirements survive.  But
> it's not real bad, and it seems a lot better than continuing with the
> fully-at-arms-length approach.
>
> Comments?

+1.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Fwd: Re: ALTER OBJECT any_name SET SCHEMA name
Next
From: "Kevin Grittner"
Date:
Subject: Re: max_wal_senders must die