Hi,
The patch needs rebasing, as it got broken by 285d8e1205, and there's some other minor bitrot. On 11/27/18 4:40 PM, Tomas Vondra wrote: > On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote: >>> >>> ...>> >>> For the main workload there's pretty much no difference, but for >>> selects from the stats catalogs there's ~20% drop in throughput. >>> In absolute numbers this means drop from ~670tps to ~550tps. I >>> haven't investigated this, but I suppose this is due to dshash >>> seqscan being more expensive than reading the data from file. >> >> Thanks for finding that. The three seqscan loops in >> pgstat_vacuum_stat cannot take such a long time, I think. I'll >> investigate it. >> > > OK. I'm not sure this is related to pgstat_vacuum_stat - the > slowdown happens while querying the catalogs, so why would that > trigger vacuum of the stats? I may be missing something, of course. > > FWIW, the "query statistics" test simply does this: > > SELECT * FROM pg_stat_all_tables; > SELECT * FROM pg_stat_all_indexes; > SELECT * FROM pg_stat_user_indexes; > SELECT * FROM pg_stat_user_tables; > SELECT * FROM pg_stat_sys_tables; > SELECT * FROM pg_stat_sys_indexes; > > and the slowdown happened even it was running on it's own (nothing > else running on the instance). Which mostly rules out concurrency > issues with the hash table locking etc. > Did you have time to investigate the slowdown? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
