On 02/23/2013 09:30 PM, Jeff Janes wrote:
Moved discussion from General To Hackers.
On Sat, Feb 23, 2013 at 10:41 AM, Stefan Andreatta
<s.andrea...@synedra.com <mailto:s.andrea...@synedra.com>> wrote:
On 02/23/2013 05:10 PM, Jeff Janes wrote:
Sorry, I got tunnel vision about the how the threshold was
computed, and forgot about the thing it was compared to. There
is a "secret" data point in the stats collector
called changes_since_analyze. This is not exposed in the
pg_stat_user_tables. But I think it should be as I often have
wanted to see it.
Sounds like a very good idea to me - any way I could help to make
such a thing happen?
It should be fairly easy to implement because the other columns are
already there to show you the way, and if you want to try your hand at
hacking pgsql it would be a good introduction to doing so.
Look at each instance in the code of n_dead_dup and
pg_stat_get_dead_tuples, and those are the places where
changes_since_analyze also need to be addressed, in an analogous
manner (assuming it is isn't already there.)
git grep 'n_dead_tup'
It looks like we would need to add an SQL function to retrieve the
data, then incorporate that function into the view definitions that
make up the pg_stat_user_tables etc. views. and of course update the
regression test and the documentation.
Other than implementing it, we would need to convince other hackers
that this is desirable to have. I'm not sure how hard that would be.
I've looked in the archives to see if this idea was already considered
but rejected, but I don't see any indication that it was previously
considered.
(http://www.postgresql.org/message-id/4823.1262132...@sss.pgh.pa.us).
Cheers,
Jeff
Not being a developer, I am afraid, I will not be going to implement it
myself - nor would anybody wish so ;-)
I also searched the archives, but the closest I found is a discussion on
the Admin List starting here:
http://www.postgresql.org/message-id/626919622.7634700.1351695913466.javamail.r...@alaloop.com
On the other hand, there is quite a lot of discussion about making
autoanalyze more (or less) aggressive - which seems a difficult task to
me, when you cannot even check what's triggering your autoanalyze.
Anybody else interested?
Regards,
Stefan
