Re: Timing of pgstats updates
От | Jan Wieck |
---|---|
Тема | Re: Timing of pgstats updates |
Дата | |
Msg-id | 419CF81B.9020406@Yahoo.com обсуждение исходный текст |
Ответ на | Timing of pgstats updates (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 11/18/2004 11:43 AM, Tom Lane wrote: > "David Parker" <dparker@tazznetworks.com> writes: >> What I think is happening with the missing pg_statistic entries: >> The install of our application involves a lot of data importing (via >> JDBC) in one large transaction, which can take up to 30 minutes. (I >> realize I left out this key piece of info in my original post...) > >> The pg_autovacuum logic is relying on data from pg_stat_all_tables to >> make the decision about running analyze. As far as I can tell, the data >> in this view gets updated outside of the transaction, because I saw the >> numbers growing while I was importing. I saw pg_autovacuum log messages >> for running analyze on several tables, but no statistics data showed up >> for these, I assume because the actual data in the table wasn't yet >> visible to pg_autovacuum because the import transaction had not finished >> yet. > >> When the import finished, not all of the tables affected by the import >> were re-visited because they had not bumped up over the threshold again, >> even though the analyze run for those tables had not generated any stats >> because of the still-open transaction. > > Bingo. The per-table activity stats are sent to the collector whenever > the backend waits for a client command. Given a moderately long > transaction block doing updates, it's not hard at all to imagine that > autovacuum would kick off vacuum and/or analyze while the updating > transaction is still in progress. The resulting operation is of course > a waste of time. > > It'd be trivial to adjust postgres.c so that per-table stats are > only transmitted when we exit the transaction (basically move the > pgstat_report_tabstat call down a couple lines so it's not called if > IsTransactionOrTransactionBlock). > > This seems like a good change to me. Does anyone not like it? > > regards, tom lane Sounds reasonable here. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: