Re: New feature: accumulative functions.

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: pasman pasmański <pasman(dot)p(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: New feature: accumulative functions.
Date: 2011-09-27 06:38:04
Message-ID: CABRT9RC_Q2kJF5TQOwapG8STSPgZ6mBXphgHeRZ-yb0wOR0wiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2011/9/25 pasman pasmański <pasman(dot)p(at)gmail(dot)com>:
> My english is not perfect, by accumulative i think about monotonically
> increasing function.
>
> It works that for clause WHERE f(x)=const:
> 1. Read root page of index_on_x and get x1 ... Xn
> 2. Calculate f(x1) ... f(xn) for this page
> 3. When f(x1)<=const<= f(xn) then x1 <= searched x <= xn and we can
> test smaller range (xlower, xgreater).
> 4. Otherwise no rows satisfy condition.

I can't get very excited about this feature for index scans. However,
I think there's another, more interesting use case: sorting

I frequently write queries like:
SELECT date_trunc('month', somedate), sum(foo)
GROUP BY date_trunc('month', somedate);

Currently the planner doesn't realize that instead of
GroupAggregate+Sort, it can use the already existing sorted index on
just (somedate). Alternatively I would need to create a separate
date_trunc functional index for daily, weekly and monthly aggregates
for EACH meaningful time zone.

This would be a planner-only change and nothing the executor needs to know of.

Now obviously HashAggregate helps a lot with these kinds of queries,
but there are still cases where GroupAggregate would be a win -- for
instance, queries with a LIMIT.

Regards,
Marti

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message tuanhoanganh 2011-09-27 06:38:14 PostgreSQL recovery when lost some file in data\global
Previous Message Venkat Balaji 2011-09-27 05:22:47 Re: : PostgreSQL Online Backup