Re: possible optimizations - pushing filter before aggregation

From: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Douglas Doole <dougdoole(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: possible optimizations - pushing filter before aggregation
Date: 2016-11-19 14:11:59
Message-ID: CAD__OuhP04+=mn0DGOytpVM_g_qWWGwJCG8DXnoJSAkhMCVk0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 19, 2016 at 8:59 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
>
>> SELECT MIN(a) m FROM
>> (SELECT a FROM t WHERE a=2) AS v(a)
>>
>> The subquery is going to return an intermediate result of:
>>
>> V:A
>> ---
>> 2
>>
>> And the minimum of that is 2, which is the wrong answer.
>>
>
> yes, you have true,
>
> In above case wondering if we could do this

Min(a) = 2 is the condition, generate condition *"a <= 2"* and push it down
as scan key. Since pushed down condition is lossy one for us ( it gives
values < 2), finally do a recheck of *"Min(a) = 2"*.

For Max(a) = 2 we can have *"a >=2"*,

If both are given we can combine them appropriately.

--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2016-11-19 14:33:08 Re: Mail thread references in commits
Previous Message Karl O. Pinc 2016-11-19 13:51:51 Re: Patch to implement pg_current_logfile() function