Re: possibility to specify template database for pg_regress

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: possibility to specify template database for pg_regress
Date: 2017-02-17 18:42:03
Message-ID: e3f112ad-3d8d-d585-4598-252377141c34@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/14/17 2:49 PM, Pavel Stehule wrote:
> > Tom's use case might be more easily served by specifying a
> > template database. I don't think Pavel ever posted his use case.
>
> Wait, that's precisely what Pavel asked?
>
>
> I would to use regress test environment in my current case. 99% code in
> plpgsql, but there is pretty complex schema. About 300 tables. 1k views.
> 2k functions. Import schema is slow. Database clonning is much faster.

FWIW, for actual production environments (which I assume this is), I
find pg_regress to be completely useless. Some simple shell scripts to
build the database (possibly using sqitch) and then a script around
pg_prove is what I normally use. https://github.com/BlueTreble/db_tools
gives you the general idea.

>> Speaking for myself, my normal pattern is to have a number of separate
>> pg_regress suites, each of which ends up loading the extension under test.
>> Loading a large extension can end up being very time consuming; enough so
>> that I'd expect it to be much faster to create the temp cluster, load all
>> the prereq's once in some template database, and then use that template for
>> most/all of the tests.
>
> I seriously doubt that. CREATE DATABASE is ridiculously expensive,
> copies everything on the file-level and requires checkpoints. If your
> extension is more expensive than that, I'd say you're likely doing
> something wrong.

That depends on the extension. pgTap for example contains over 900
functions. A quick test on my laptop shows it's faster to create a
database from a template containing the extension than it is to create
the extension itself.

decibel(at)decina:[12:33]~$time createdb t

real 0m0.433s
user 0m0.004s
sys 0m0.009s
decibel(at)decina:[12:34]~$time psql -c 'create extension pgtap' t
CREATE EXTENSION

real 0m0.559s
user 0m0.002s
sys 0m0.007s
decibel(at)decina:[12:34]~$time createdb -T t t2

real 0m0.441s
user 0m0.002s
sys 0m0.005s
decibel(at)decina:[12:34]~$time psql -c 'drop extension pgtap' t
DROP EXTENSION

real 0m0.197s
user 0m0.002s
sys 0m0.006s
decibel(at)decina:[12:34]~$time dropdb t

real 0m0.189s
user 0m0.003s
sys 0m0.007s
decibel(at)decina:[12:34]~$time dropdb t2

real 0m0.154s
user 0m0.002s
sys 0m0.005s
decibel(at)decina:[12:34]~$

Interestingly, CREATE EXTENSION is 2x faster than simply running the file:

decibel(at)decina:[12:38]~$time psql -qtf
$PGDATA/../share/extension/pgtap--0.97.0.sql t

real 0m1.225s
user 0m0.044s
sys 0m0.028s
decibel(at)decina:[12:39]~$

decibel(at)decina:[12:41]~$(echo 'begin;'; echo "\i
$PGDATA/../share/extension/pgtap--0.97.0.sql"; echo 'commit;') | time
psql -qt t
1.12 real 0.04 user 0.02 sys
decibel(at)decina:[12:41]~$
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-02-17 19:00:25 Re: Reporting xmin from VACUUMs
Previous Message Tom Lane 2017-02-17 18:21:25 Re: pg_recvlogical.c doesn't build with --disable-integer-datetimes