Re: mat views stats

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Mlodgenski <jimmy76(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-18 21:57:47
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Jim Mlodgenski <jimmy76(at)gmail(dot)com> writes:
> 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.

I've pushed this into HEAD with one non-cosmetic change: the patch tried
to pass a uint64 tuple count to pgstat_count_heap_insert(), whose argument
was only declared as "int". This would go seriously wrong with matviews
having more than INT_MAX rows, which hardly seems out of the question,
so I changed pgstat_count_heap_insert() to take int64 instead.

I don't think we can make that change in the back branches though.
It seems too likely that third-party code might be calling

We could possibly kluge around this to produce a safe-to-back-patch
fix by doing something like

pgstat_count_heap_insert(matviewRel, (int) Min(processed, INT_MAX));

But that seems pretty ugly. Given the lack of previous reports, I'm
personally content to leave this unfixed in the back branches.


regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-03-18 22:22:43 Re: [PATCH] SortSupport for macaddr type
Previous Message Peter Geoghegan 2017-03-18 21:54:03 Re: [PATCH] SortSupport for macaddr type