On Mon, Jul 2, 2012 at 5:33 PM, Robert Haas wrote:
> On Thu, Jun 28, 2012 at 10:22 PM, Etsuro Fujita
> wrote:
>> Honestly, I'm not sure that it's worth including this, considering the use
>> case...
>
> Since nobody seems crazy about pursuing this, I'm marking this patch Rejected.
Thank you, for
On Thu, Jun 28, 2012 at 10:22 PM, Etsuro Fujita
wrote:
> Honestly, I'm not sure that it's worth including this, considering the use
> case...
Since nobody seems crazy about pursuing this, I'm marking this patch Rejected.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Po
Hi Ants,
> -Original Message-
> From: Ants Aasma [mailto:a...@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
Sorry about the delay in answering. I have been swamped with non-PG
related things lately.
On Tue, Jun 26, 2012 at 11:08 PM, Robert Haas wrote:
> On Fri, Jun 22, 2012 at 10:12 AM, Robert Haas wrote:
>> On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
>> wrote:
I'm confused by this remark, be
Hi,
> -Original Message-
> From: Robert Haas [mailto:robertmh...@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 w
On Fri, Jun 22, 2012 at 10:12 AM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
> wrote:
>>> I'm confused by this remark, because surely the query planner does it this
>>> way only if there's no LIMIT. When there is a LIMIT, we choose based on
>>> the startup cost plus the
On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
wrote:
>> I'm confused by this remark, because surely the query planner does it this
>> way only if there's no LIMIT. When there is a LIMIT, we choose based on
>> the startup cost plus the estimated fraction of the total cost we expect
>> to pay base
Hi,
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Tuesday, June 19, 2012 3:12 AM
> To: Ants Aasma
> Cc: Etsuro Fujita; Jay Levitt; Tom Lane; PostgreSQL-development; Francois
> Deliege
> Subject: Re: [HACKERS] [PATCH] Lazy hashaggregat
On Fri, Jun 15, 2012 at 9:22 AM, Ants Aasma wrote:
> Exactly. I think the first question for this patch should be whether
> this use-case is worth the complexity of the patch. I can't imagine
> any really compelling use cases that need an arbitrary distinct subset
> of results.
Me neither.
> The
On Fri, Jun 15, 2012 at 3:13 PM, Robert Haas wrote:
> However, as Ants points out, we could make it work better for the
> special case where we're not actually doing any aggregation, because
> in that case we can emit the row for each group when the group is
> created, rather than waiting until en
On Fri, Jun 15, 2012 at 6:55 AM, Etsuro Fujita
wrote:
A user complained on pgsql-performance that SELECT col FROM table
GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
to return tuples from hash-aggregate as they are found when no
aggregate functions are i
Hi,
I would like to ask a question before looking into the patch.
At 21:56 12/03/30 -0400, Jay Levitt wrote:
Tom Lane wrote:
Ants Aasma writes:
A user complained on pgsql-performance that SELECT col FROM table
GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
to return tup
Tom Lane wrote:
Ants Aasma writes:
A user complained on pgsql-performance that SELECT col FROM table
GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
to return tuples from hash-aggregate as they are found when no
aggregate functions are in use. Attached is a first shot at th
Ants Aasma writes:
> A user complained on pgsql-performance that SELECT col FROM table
> GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
> to return tuples from hash-aggregate as they are found when no
> aggregate functions are in use. Attached is a first shot at that.
As I
A user complained on pgsql-performance that SELECT col FROM table
GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
to return tuples from hash-aggregate as they are found when no
aggregate functions are in use. Attached is a first shot at that. The
planner is modified so that wh
15 matches
Mail list logo
