Re: 60 core performance with 9.3

From: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
To: "Mark Kirkwood" <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: "Andres Freund" <andres(at)2ndquadrant(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: 60 core performance with 9.3
Date: 2014-07-30 08:42:17
Message-ID: 3e6b532b0115ffff08e8d0debd76695b.squirrel@sq.gransy.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 30 Červenec 2014, 3:44, Mark Kirkwood wrote:
>
> While these numbers look great in the middle range (12-96 clients), then
> benefit looks to be tailing off as client numbers increase. Also running
> with no stats (and hence no auto vacuum or analyze) is way too scary!

I assume you've disabled statistics collector, which has nothing to do
with vacuum or analyze.

There are two kinds of statistics in PostgreSQL - data distribution
statistics (which is collected by ANALYZE and stored in actual tables
within the database) and runtime statistics (which is collected by the
stats collector and stored in a file somewhere on the dist).

By disabling statistics collector you loose runtime counters - number of
sequential/index scans on a table, tuples read from a relation aetc. But
it does not influence VACUUM or planning at all.

Also, it's mostly async (send over UDP and you're done) and shouldn't make
much difference unless you have large number of objects. There are ways to
improve this (e.g. by placing the stat files into a tmpfs).

Tomas

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tomas Vondra 2014-07-30 09:01:55 Re: Why you should turn on Checksums with SSDs
Previous Message Rural Hunter 2014-07-30 04:16:36 Re: Very slow planning performance on partition table