Comments (8)
Thanks for your comments - it's great to get feedback. This module does not currently support GROUP BY functions - you'd need to use the complete refresh option provided by Postgres to support this. And, partitioning hasn't been tested so at the moment this isn't supported but any ideas and contribution would be most appreciated.
We're reviewing our latest internally code set currently and we hope to get this into the base line master branch in the next few weeks with all the latest changes and bug fixes we've done.
Thanks again for your feedback.
from pg-mv-fast-refresh.
Is this issue solved? When will master be updated with the latest changes?
from pg-mv-fast-refresh.
Hello,
We were using this module for a while and it worked really well at the beginning, after some time, the database increased in size and some tables reached 100GB of size and the fast refresh function started to take so much time to process the fast refresh.
What we have been doing is to remove the materialized views and re-create them with the provided application functions and prune the mv logs involved with a simple truncate (yes, the mv logs were not removed at all for some tables).
We noticed that the cursor which obtains the pending rows to be processed into the materialized view in the following line
was taking more time on each iteration even with one single change to be processed.
Any hints on this or suggestions on what we are missing?
Thanks
from pg-mv-fast-refresh.
Is this issue solved? When will master be updated with the latest changes?
Master has been updated.
from pg-mv-fast-refresh.
Hello, We were using this module for a while and it worked really well at the beginning, after some time, the database increased in size and some tables reached 100GB of size and the fast refresh function started to take so much time to process the fast refresh.
What we have been doing is to remove the materialized views and re-create them with the provided application functions and prune the mv logs involved with a simple truncate (yes, the mv logs were not removed at all for some tables).
We noticed that the cursor which obtains the pending rows to be processed into the materialized view in the following line
was taking more time on each iteration even with one single change to be processed.
Any hints on this or suggestions on what we are missing?
Thanks
I pushed our latest code set up in the past couple of months - there have been a number of changes and improvements. Probably worth testing this can see if it works any better from a performance point of view.
from pg-mv-fast-refresh.
Hello, We were using this module for a while and it worked really well at the beginning, after some time, the database increased in size and some tables reached 100GB of size and the fast refresh function started to take so much time to process the fast refresh.
What we have been doing is to remove the materialized views and re-create them with the provided application functions and prune the mv logs involved with a simple truncate (yes, the mv logs were not removed at all for some tables).
We noticed that the cursor which obtains the pending rows to be processed into the materialized view in the following line
was taking more time on each iteration even with one single change to be processed.
Any hints on this or suggestions on what we are missing?
ThanksI pushed our latest code set up in the past couple of months - there have been a number of changes and improvements. Probably worth testing this can see if it works any better from a performance point of view.
Be good to get some feedback if you've tested the latest code setup? Thanks
from pg-mv-fast-refresh.
Is this issue solved? When will master be updated with the latest changes?
Master has been updated.
@dday01 Does this mean GROUP BY
queries are working now?
From what I can see, that functionality is not present in master.
from pg-mv-fast-refresh.
Related Issues (7)
- Problems with dropping MV logs HOT 1
- Exception in function mv$addrow$tomv$table when trying to add two mv sharing the same base table
- ERROR: duplicate key value violates unique constraint "pk_test_17" HOT 2
- Composite primary keys
- Exception in function mv$clearPgMvLogTableBits Error 40P01:- deadlock detected HOT 2
- INFO: Exception in function mv$insertOuterJoinRows INFO: Error 22004:- query string argument of EXECUTE is null:
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pg-mv-fast-refresh.