On 22 May 2017 at 03:14, Riaan Stander wrote:
>
>> Riaan Stander 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
Riaan Stander 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. To batch them together and get output from on
Riaan Stander 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. To batch them together and get output
Riaan Stander 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 creati
Riaan Stander 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" functio
Would turning on logging of temp files help? That often reports the query
that is using the temp files:
log_temp_files = 0
It probably wouldn't help if the cursor query never pulls from a temp file,
but if it does ...
On Fri, May 19, 2017 at 7:04 PM, Jeff Janes wrote:
> I'm spoiled by using pg
