From: Tom Lane <tgl@sss.pgh.pa.us>
To: Riaan Stander <rstander@exa.co.za>
cc: pgsql-performance@postgresql.org
Subject: Re: Bulk persistence strategy
In-reply-to: <15c29aeedc8.27e1.e05fafc80f8daf1488764675043d44fb@exa.co.za>
References: <04c901d2a753$f55de020$e019a060$@exa.co.za>
 <15c29aeedc8.27e1.e05fafc80f8daf1488764675043d44fb@exa.co.za>
Comments: In-reply-to Riaan Stander <rstander@exa.co.za>
	message dated "Sun, 21 May 2017 08:25:49 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32402.1495377186.1@sss.pgh.pa.us>
Date: Sun, 21 May 2017 10:33:06 -0400
Message-ID: <32403.1495377186@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Riaan Stander <rstander@exa.co.za> writes:
> I've come up with generating functions on the go, but I'm concerned about 
> the performance impact of this. I first wanted to use an anonoumys code 
> block, but then I cannot do parameter binding from npgsql.
> ...
> Is there a better way I'm missing and is "temp" function creation in 
> Postgres a big performance concern, especially if a server is under load?

The function itself is only one pg_proc row, but if you're expecting
to do this thousands of times a minute you might have to adjust autovacuum
settings to avoid bad bloat in pg_proc.

If you're intending that these functions be use-once, it's fairly unclear
to me why you bother, as opposed to just issuing the underlying SQL
statements.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance