Re: Idea: GSoC - Query Rewrite with Materialized Views

From: Eric Grinstein <eric(at)aluno(dot)puc-rio(dot)br>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea: GSoC - Query Rewrite with Materialized Views
Date: 2015-03-03 20:30:44
Message-ID: CAK7uWEwwA5uae4rkfDcuCz0DiP3EVLRUKBtDGRdb=YFx-a6Huw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> I think even something that just does that in pure SQL/plpgsql would be a
> big step forward, even if we wouldn't want it directly in the codebase.

Something like creating a trigger under the hood each time a MV is created,
that checks the changed rows on every statement against the query that
generated the MV? That also seems feasible, but wouldn't it be rather too
small for my three months of GSoC?

2015-03-02 20:22 GMT-03:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 3/2/15 9:03 AM, Kevin Grittner wrote:
>
>> The query rewrite feature would be extremely desirable for us.
>>> >Do you think that implementing the staleness check as suggested
>>> >by Thomas could get us started in the query rewrite business?
>>>
>> There are many aspects related to the definition, maintenance, and
>> use of MVs that need work; it seems to me that many of them can be
>> pursued in parallel as long as people are communicating. Staleness
>> tracking is definitely one aspect that is needed. If you want to
>> put forward a proposal for that, which seems to be of a scope that
>> is possible in the context of GSoC, that would be great. If there
>> is any other aspect of the MV "big picture" that you can think of
>> that you would like to tackle and seems of appropriate scope,
>> please don't feel constrained to "staleness" as the only possible
>> project; it was just one suggestion of something that might be of
>> about the right size.
>>
>
> FWIW, what I would find most useful at this point is a way to get the
> equivalent of an AFTER STATEMENT trigger that provided all changed rows in
> a MV as the result of a statement. That would at least allow people do do
> their own MV refresh work without needing to study the methods for
> identifying how the results of a statement impact what should be in the MV.
> I think even something that just does that in pure SQL/plpgsql would be a
> big step forward, even if we wouldn't want it directly in the codebase.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-03-03 20:36:07 Re: Patch: raise default for max_wal_segments to 1GB
Previous Message Corey Huinker 2015-03-03 20:22:52 Re: Patch: raise default for max_wal_segments to 1GB