Jim Mlodgenski <jimm...@gmail.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
pgstat_count_heap_insert().
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.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
