Re: [HACKERS] mat views stats - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] mat views stats
Date
Msg-id 9698.1489874267@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] mat views stats  (Jim Mlodgenski <jimmy76@gmail.com>)
Responses Re: [HACKERS] mat views stats  (Jim Mlodgenski <jimmy76@gmail.com>)
List pgsql-hackers
Jim Mlodgenski <jimmy76@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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] [PATCH] SortSupport for macaddr type
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] [PATCH] SortSupport for macaddr type