From: "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>
To: "'Ants Aasma'" <ants@cybertec.at>, "'Robert Haas'" <robertmhaas@gmail.com>
Cc: "'Jay Levitt'" <jay.levitt@gmail.com>, "'Tom Lane'" <tgl@sss.pgh.pa.us>,
	"'PostgreSQL-development'" <pgsql-hackers@postgresql.org>,
	"'Francois Deliege'" <fdeliege@gmail.com>
References: 
 <CA+CSw_uE-RCyQd_bXJNe=usrXkq+keFrQrahkc+8ou+Ws4Y=Vw@mail.gmail.com>
	<22709.1332944158@sss.pgh.pa.us>	<4F766454.9040909@gmail.com>
	<4.3.2-J.20120615194845.03a6fa20@129.60.53.11>
	<CA+TgmoamkSz1wyfU1CF8URChNJDCXTFrO23p9tsdCWiB5i2CYw@mail.gmail.com>
	<CA+CSw_vMYNKU9kAEO0w+TZBrFxLMQfz6gdO4hNq+pR96d4DS5w@mail.gmail.com>
	<CA+TgmoanPggSnpMgA5J15EQjm-+7xdq6FaFwkcnaRSXT8A7uAw@mail.gmail.com>
	<004a01cd4dff$bffd9a40$3ff8cec0$@lab.ntt.co.jp>
	<CA+TgmoamUGSAch8o_SF0-N=tix6XZz_t9RJn0js=0=G2tBBtVA@mail.gmail.com>
	<CA+TgmoaRPgCTLYVsb-zZ1mem2rPW6bGodwQ_8-2=HvY-YbZzrw@mail.gmail.com>
	<CA+CSw_t=qHA5GxH8ZVn3uTzPCee=hkDRLrNMGtU2PSYHPHVu8g@mail.gmail.com>
In-Reply-To: 
 <CA+CSw_t=qHA5GxH8ZVn3uTzPCee=hkDRLrNMGtU2PSYHPHVu8g@mail.gmail.com>
Subject: Re: [PATCH] Lazy hashaggregate when no aggregation is needed
Date: Fri, 29 Jun 2012 11:22:15 +0900
Message-ID: <00aa01cd559d$ffb32790$ff1976b0$@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: 
 AQFW5RmpuYBQ1Q1EBonax2VVtvN1QQHJ2D4OAp/TGtACUg7+gAJCiNmTAtG+D6UBAUClRQI2ULBxA0s/DkEB62i7xQHRJw9Wl0z2dHA=
Content-Language: ja

Hi Ants,

> -----Original Message-----
> From: Ants Aasma [mailto:ants@cybertec.at]
> Sent: Wednesday, June 27, 2012 9:23 PM
> To: Robert Haas
> Cc: Etsuro Fujita; Jay Levitt; Tom Lane; PostgreSQL-development; =
Francois
> Deliege
> Subject: Re: [HACKERS] [PATCH] Lazy hashaggregate when no aggregation =
is
needed
>=20
> Sorry about the delay in answering. I have been swamped with non-PG
> related things lately.
>=20
> On Tue, Jun 26, 2012 at 11:08 PM, Robert Haas <robertmhaas@gmail.com> =
wrote:
> > On Fri, Jun 22, 2012 at 10:12 AM, Robert Haas =
<robertmhaas@gmail.com> wrote:
> >> On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
> >> <fujita.etsuro@lab.ntt.co.jp> wrote:
> >>>> I'm confused by this remark, because surely the query planner =
does it
this
> >>>> way only if there's no LIMIT. =A0When there is a LIMIT, we choose =
based on
> >>>> the startup cost plus the estimated fraction of the total cost we =
expect
> >>>> to pay based on dividing the LIMIT by the overall row count =
estimate. =A0Or
> >>>> is this not what you're talking about?
>=20
> My reasoning was that query_planner returns the cheapest-total path
> and cheapest fractional presorted (by the aggregation pathkeys). When
> evaluating hash-aggregates with this patch these two are indeed
> compared considering the esimated fraction of the total cost, but this
> might miss cheapest fractional unordered path for lazy hashaggregates.
>=20
> Reviewing the code now I discovered this path could be picked out from
> the pathlist, just like it is done by
> get_cheapest_fractional_path_for_pathkeys when pathkeys is nil. This
> would need to be returned in addition to the other two paths. To
> minimize overhead, this should only be done when we possibly want to
> consider lazy hash-aggregation (there is a group clause with no
> aggregates and grouping is hashable) But this is starting to get
> pretty crufty considering that there doesn't seem to be any really
> compelling usecases for this.
>=20
> > Ants, do you intend to update this patch for this CommitFest? =A0Or =
at
> > all? =A0It seems nobody's too excited about this, so I'm not sure
> > whether it makes sense for you to put more work on it. =A0But please
> > advise as to your plans.
>=20
> If anyone thinks that this patch might be worth considering, then I'm
> prepared to do minor cleanup this CF (I saw some possibly unnecessary
> cruft in agg_fill_hash_and_retrieve). On the other hand, if you think
> the use case is too marginal to consider for inclusion then I won't
> shed a tear if this gets rejected. For me this was mostly a learning
> experience for poking around in the planner.

Honestly, I'm not sure that it's worth including this, considering the =
use
case...

Thanks,

Best regards,
Etsuro Fujita

> Ants Aasma
> --
> Cybertec Sch=F6nig & Sch=F6nig GmbH
> Gr=F6hrm=FChlgasse 26
> A-2700 Wiener Neustadt
> Web: http://www.postgresql-support.de
>=20