Re: Turning off HOT/Cleanup sometimes

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2015-03-12 00:55:18
Message-ID: 5500E3F6.5030008@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/9/15 1:36 PM, Jeff Janes wrote:
> Did versions 7 and 8 of this patch address Andres' concern about
> performance regressions?

I don't think so. Andres basically wanted a nontrival algorithm to
determine how much pruning to do during a read-only scan. And Robert
basically said, that's not really possible.

The presented patch actually has a hardcoded prune limit of 4 per scan,
which I don't see mentioned in the discussion anywhere (except in very
early versions, where this was exposed as a knob).

I think most people were of the opinion that scans on system catalogs
should not be affected by this behavior change. Makes sense to me:
System catalog bloat is likely a bigger problem than speeding up queries
on catalogs with large live data.

And then there is still some disagreement whether just turning this on
is tolerable for all uses. Andres mentioned workloads that have trouble
getting a cleanup lock. README.HOT seems to think that cleaning up
during reads is important because skipping over dead tuples is
expensive. Nobody seems to like the idea of (implicitly) pushing more
responsibility on VACUUM. We have seen some benchmarks that show
significant improvements. We have seen some (constructed ones) that
show problems.

I don't know how to move forward. We could give users a knob: This
might make your queries faster or not -- good luck. But of course
nobody will like that either.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-03-12 01:13:11 Re: logical column ordering
Previous Message Noah Misch 2015-03-12 00:46:23 Re: Stateful C-language function with state managed by third-party library