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
