Re: New GUC to sample log queries

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New GUC to sample log queries
Date: 2018-05-31 01:34:19
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 31 May 2018 at 06:44, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info> wrote:
> Here is a naive SELECT only bench with a dataset which fit in ram (scale factor
> = 100) and PGDATA and log on a ramdisk:
> shared_buffers = 4GB
> seq_page_cost = random_page_cost = 1.0
> logging_collector = on (no rotation)

It would be better to just: SELECT 1; to try to get the true overhead
of the additional logging code.

> I don't know the cost of random() call?

It's probably best to test in Postgres to see if there's an overhead
to the new code. It may be worth special casing the 0 and 1 case so
random() is not called.

+ (random() < log_sample_rate * MAX_RANDOM_VALUE);

this should be <=, or you'll randomly miss logging a query when
log_sample_rate is 1.0 every 4 billion or so queries.

Of course, it would be better if we had a proper profiler, but I can
see your need for this. Enabling logging of all queries in production
is currently reserved for people with low traffic servers and the

David Rowley
PostgreSQL Development, 24x7 Support, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Carter Thaxton 2018-05-31 01:49:06 Re: Add --include-table-data-where option to pg_dump, to export only a subset of table data
Previous Message Thomas Munro 2018-05-30 22:57:30 Re: Undo logs