pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedFrom: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: alvherre@2ndquadrant.com
Cc: andres@anarazel.de
Cc: ah@cybertec.at
Cc: magnus@hagander.net
Cc: robertmhaas@gmail.com
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgresql.org
Subject: Re: shared-memory based stats collector
Date: Sun, 20 Jan 2019 18:13:04 +0100
Message-ID: <b760035b-1941-38bb-5e84-c2fbc63fef6b@2ndquadrant.com> (raw)
In-Reply-To: <06f751c9-e400-3742-83f1-3f2292297622@2ndquadrant.com>
References: <20181112.201042.147595779.horiguchi.kyotaro@lab.ntt.co.jp>
<8e041a34a70ae5d44cb10a7e516308e2f6d1b651.camel@2ndquadrant.com>
<6c079a69-feba-e47c-7b85-8a9ff31adef3@2ndquadrant.com>
<20181127.175949.06807946.horiguchi.kyotaro@lab.ntt.co.jp>
<06f751c9-e400-3742-83f1-3f2292297622@2ndquadrant.com>
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
view thread (238+ messages) latest in thread
Message-ID: <b760035b-1941-38bb-5e84-c2fbc63fef6b@2ndquadrant.com>
Permalink: ../b760035b-1941-38bb-5e84-c2fbc63fef6b@2ndquadrant.com/
Also on: postgresql.org/message-id/b760035b-1941-38bb-5e84-c2fbc63fef6b@2ndquadrant.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, horiguchi.kyotaro@lab.ntt.co.jp, alvherre@2ndquadrant.com, andres@anarazel.de, ah@cybertec.at, magnus@hagander.net, robertmhaas@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: shared-memory based stats collector
In-Reply-To: <b760035b-1941-38bb-5e84-c2fbc63fef6b@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox