Re: postgres materialized view refresh performance

2020-10-26 Thread Philip Semanchuk
> On Oct 26, 2020, at 10:45 AM, Ayub M wrote: > > It's a simple sequential scan plan of one line, just reading the base table > sequentially. Well, unless I have misunderstood you, the materialized view is basically just "select * from some_other_table”, the number of records in the source

Re: postgres materialized view refresh performance

2020-10-26 Thread Ayub M
It's a simple sequential scan plan of one line, just reading the base table sequentially. On Mon, Oct 26, 2020, 9:21 AM Philip Semanchuk wrote: > > > > On Oct 25, 2020, at 10:52 PM, Ayub M wrote: > > > > Thank you both. > > > > As for the mview refresh taking long -- > > • The mview gets refr

Re: postgres materialized view refresh performance

2020-10-26 Thread Philip Semanchuk
> On Oct 25, 2020, at 10:52 PM, Ayub M wrote: > > Thank you both. > > As for the mview refresh taking long -- > • The mview gets refreshed in a couple of mins sometimes and sometimes it > takes hours. When it runs for longer, there are no locks and no resource > shortage, the number of re

Re: postgres materialized view refresh performance

2020-10-25 Thread Ayub M
Thank you both. As for the mview refresh taking long -- • The mview gets refreshed in a couple of mins sometimes and sometimes it takes hours. When it runs for longer, there are no locks and no resource shortage, the number of recs in the base table is 6m (7.5gb) which is not huge so why does it

Re: postgres materialized view refresh performance

2020-10-23 Thread Philip Semanchuk
> On Oct 23, 2020, at 9:52 AM, Ravi Krishna wrote: > >> My understanding is that when CONCURRENTLY is specified, Postgres implements >> the refresh as a series of INSERT, UPDATE, >> and DELETE statements on the existing view. So the answer to your question >> is no, Postgres doesn’t create a

Re: postgres materialized view refresh performance

2020-10-23 Thread Ravi Krishna
> My understanding is that when CONCURRENTLY is specified, Postgres implements > the refresh as a series of INSERT, UPDATE, > and DELETE statements on the existing view. So the answer to your question is > no, Postgres doesn’t create another table and > then swap it. The INSERTS/UPDATE/DELETE ha

Re: postgres materialized view refresh performance

2020-10-23 Thread Philip Semanchuk
> On Oct 22, 2020, at 3:53 PM, Ayub M wrote: > > There is a table t which is used in a mview mv, this is the only table in the > mview definition. > > create table t (c1 int, ..., c10 int > ); > > -- there is a pk on say c1 column > create materialized view mv as select c1, c2...c10 from >