From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Riaan Stander <rstander(at)exa(dot)co(dot)za>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Bulk persistence strategy |
Date: | 2017-05-22 15:37:52 |
Message-ID: | CAHyXU0xz9oGMoM26bc3-RbEb0wtMycrMzxos6wnpaB4jtKmAPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sun, May 21, 2017 at 5:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Riaan Stander <rstander(at)exa(dot)co(dot)za> writes:
>> The intended use is use-once. The reason is that the statements might
>> differ per call, especially when we start doing updates. The ideal would
>> be to just issue the sql statements, but I was trying to cut down on
>> network calls.
>
> Hm, well, feeding data forward to the next query without a network
> round trip is a valid concern.
>
> How stylized are these commands? Have you considered pushing the
> generation logic into the function, so that you just have one (or
> a few) persistent functions, and the variability slack is taken
> up through EXECUTE'd strings?
+1. If 'DO' could return a value and take arguments, we'd probably
just use that. With the status quo however the SQL generation
facilities need to be moved into the database as dynamic SQL (that is,
executed with EXECUTE). This will provide the speed benefits while
maintaining (albeit with some rethinking) your abstraction model
Please make liberal use of quote_ident() and quote_literal() to
minimize security risks.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-05-22 19:57:39 | select subquery versus join subquery |
Previous Message | Ariel | 2017-05-22 15:17:31 | index of only not null, use function index? |