Hi Nico,
By the way, I do agree with your point about MERGE — if we can factor MV
updates in that fashion, it will certainly save.
I didn’t reply immediately because your point caught me off guard:
> […] If you look at my
> sketch for how to do it, you'll notice that many of the sorts of queri
On Tue, Jun 19, 2018 at 08:46:06AM +0100, Dent John wrote:
> I’m pretty impressed anything in this space can be written entirely in
> PlPGQSL!
https://github.com/twosigma/postgresql-contrib
PG is quite powerful!
I have even implemented a COMMIT TRIGGER in pure PlPgSQL.
You'll notice I make exte
Hi Nico,
I’m pretty impressed anything in this space can be written entirely in PlPGQSL!
If you did integrate your implementation, it would be easy for my Extension to
read from a table other than the one which it gets the MV definition from...
Although having said that, if you went down the ro
On Mon, Jun 18, 2018 at 07:38:13PM +0100, Dent John wrote:
> I commented to Corey (privately) that, while my rewrite extension has
> gotten me a server that responds quickly to aggregate queries, the
> constant need to refresh the supporting MVs means the system’s load
> average is constant and muc
I commented to Corey (privately) that, while my rewrite extension has gotten me
a server that responds quickly to aggregate queries, the constant need to
refresh the supporting MVs means the system’s load average is constant and much
higher than before. I’m happy with the tradeoff for now, but i
>
> Hope it is useful or interesting for someone! Questions or comments are
>> very welcome.
>>
>
> good idea.
>
> Regards
>
> Pavel
>
In a recent PgConf NYC presentation [1] I was talking about the technical
hurdles to implementing materialized views that could be kept up to date at
all times, an
2018-06-16 16:21 GMT+02:00 John Dent :
> Hi folks,
>
> I thought I’d share an update to my pet project, which dynamically
> rewrites queries to target materialized views when they are available and
> can satisfy a query (or part of it) with a lower cost plan.
>
> The extension is now a regular EXT
Hi folks,
I thought I’d share an update to my pet project, which dynamically rewrites
queries to target materialized views when they are available and can satisfy a
query (or part of it) with a lower cost plan.
The extension is now a regular EXTENSION and no longer tied in to the FDW
mechanism
