Re: Limiting setting of hint bits by read-only queries; vacuum_delay

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Limiting setting of hint bits by read-only queries; vacuum_delay
Date: 2013-03-25 20:44:43
Message-ID: 1364244283.30049.YahooMailNeo@web162902.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

>> we need testing against real world workloads, or at least a much
>> better synthetic one than pgbench, which per recent discussions
>> is probably the top objective of the project (a performance
>> farm, etc.).
>
> Self-tuning the background workloads needs lots of testing.
> Limiting foreground work needs very little, or none.

This is absolutely a real-world problem, but I disagree that the
solution you propose is risk-free.  It would be trivial to
construct a test which would show massive performance degradation.
Consider a single largish table which fits in cache and is subject
to frequent seqscans, and a workload which burns through
transaction IDs fast enough to cause clog thrashing as these xids
get old and still lack hint bits.

I think there are ways to deal with that problem, with the
foreground select telling the bgwriter or autovacuum to pay
attention to the problem tables (or pages), but now is not the time
to start designing that.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-03-25 21:21:38 Re: Limiting setting of hint bits by read-only queries; vacuum_delay
Previous Message Bruce Momjian 2013-03-25 19:51:18 Re: Let's invent a function to report lock-wait-blocking PIDs