From: "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>
To: "'Robert Haas'" <robertmhaas@gmail.com>
Cc: "'Ants Aasma'" <ants@cybertec.at>, "'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>
In-Reply-To: 
 <CA+TgmoaRPgCTLYVsb-zZ1mem2rPW6bGodwQ_8-2=HvY-YbZzrw@mail.gmail.com>
Subject: Re: [PATCH] Lazy hashaggregate when no aggregation is needed
Date: Wed, 27 Jun 2012 12:53:40 +0900
Message-ID: <003e01cd5418$706dba40$51492ec0$@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/DkEB62i7xZdYdJGw
Content-Language: ja

Hi,

> -----Original Message-----
> From: Robert Haas [mailto:robertmhaas@gmail.com]
> Sent: Wednesday, June 27, 2012 5:09 AM
> To: Etsuro Fujita
> Cc: Ants Aasma; Jay Levitt; Tom Lane; PostgreSQL-development; Francois =
Deliege
> Subject: Re: [HACKERS] [PATCH] Lazy hashaggregate when no aggregation =
is
needed
>=20
> 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?
> >>
> >> I think that Ants is pointing the way of estimating costs in
> >> choose_hashed_grouping()/choose_hashed_distinct(), ie cost_agg() =
for
> >> cheapest_path + hashagg, where the costs are calculated based on =
the total
> >> cost only of cheapest_path. =A0I think that it might be good to do =
cost_agg()
> >> for the discussed case with the AGG_SORTED strategy, not the =
AGG_HASHED
> >> strategy.
> >
> > Well, Ants already made some adjustments to those functions; not =
sure
> > if this means they need some more adjustment, but I don't see that
> > there's a general problem with the costing algorithm around LIMIT.
>=20
> Ants, do you intend to update this patch for this CommitFest?  Or at
> all?  It seems nobody's too excited about this, so I'm not sure
> whether it makes sense for you to put more work on it.  But please
> advise as to your plans.

Please excuse my slow response, I would also like to know your plan.

Best regards,
Etsuro Fujita

> Thanks,
>=20
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>=20