Re: Another modest proposal for reducing CLOBBER_CACHE_ALWAYS runtime

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Another modest proposal for reducing CLOBBER_CACHE_ALWAYS runtime
Date: 2021-05-10 06:57:48
Message-ID: CAApHDvrGnVmZ+cZvoNLO-wDhJ+ACP9dSKOcXw=6F0D24=hYZ-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 10 May 2021 at 18:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I dug into it and found that the core issue is much like that in
> opr_sanity.sql, namely that we're repeating this plpgsql function
> $bignum times:
>
> CREATE FUNCTION leak(integer,integer) RETURNS boolean
> AS $$begin return $1 < $2; end$$
> LANGUAGE plpgsql immutable;

> real 293m31.054s
> to
> real 1m47.807s
>
> Yes, really.

That's quite impressive.

I've very much in favour of this change. Making it more realistic to
run the regression tests on a CLOBBER_CACHE_ALWAYS builds before a
commit is a very worthy goal and this is a big step towards that.
Nice.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-05-10 06:58:56 Re: Allow batched insert during cross-partition updates
Previous Message vignesh C 2021-05-10 06:53:37 Re: [HACKERS] logical decoding of two-phase transactions