Re: mat views stats

From: Jim Mlodgenski <jimmy76(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mat views stats
Date: 2017-03-01 22:20:34
Message-ID: CAB_5SRds3h_pgsS=EBv0S8fX5je0yHJQW7MzJh85oV4XdzHhvQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Sun, Feb 26, 2017 at 11:49 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Feb 22, 2017 at 11:13 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
> wrote:
> > Certainly easier, but I don't think it'd be better. Matviews really
> aren't
> > the same thing as tables. Off-hand (without reviewing the patch), update
> and
> > delete counts certainly wouldn't make any sense. "Insert" counts might,
> in
> > as much as it's how many rows have been added by refreshes. You'd want a
> > refresh count too.
>
> Regular REFRESH truncates the view and repopulates it, but REFRESH
> CONCURRENTLY does inserts, updates, and deletes as needed to adjust
> the contents. So I think all the same counters that make sense for
> regular tables are also sensible here.
>
>
After digging into things further, just making refresh report the stats for
what is it basically doing simplifies and solves it and it is something we
can back patch if that the consensus. See the attached patch.

Attachment Content-Type Size
refresh_matview_stats.patch text/x-patch 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-03-01 22:20:57 Re: logical decoding of two-phase transactions
Previous Message Jim Nasby 2017-03-01 22:15:09 Re: GSoC 2017