On Thu, Aug 10, 2017 at 6:21 PM, Mark Dilger wrote:
> That misses the point I was making. I was suggesting a syntax where
> the caller promises to use all rows without stopping short, and the
> database performance problems of having a bunch of parallel workers
> suspended in mid query is simply
> On Aug 10, 2017, at 11:20 AM, Robert Haas wrote:
>
> On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger wrote:
>> I can understand this, but wonder if I could use something like
>>
>> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
>> ...
>> END LOOP;
>
> Actually, what you'd need i
On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger wrote:
> I can understand this, but wonder if I could use something like
>
> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
> ...
> END LOOP;
Actually, what you'd need is:
FOR I TOTALLY PROMISE TO USE ALL ROWS AND IT IS OK TO BUFFER THE
> On Jul 5, 2017, at 5:30 AM, Amit Kapila wrote:
>
> On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote:
>>
>>> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote:
>>>
>>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
On 30 June 2017 at 05:14, Amit Kapila wrote:
> This is ex
On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote:
>
>> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote:
>>
>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
>>> On 30 June 2017 at 05:14, Amit Kapila wrote:
>>>
This is explained in section 15.2 [1], refer below para:
"The query mig
> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote:
>
> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
>> On 30 June 2017 at 05:14, Amit Kapila wrote:
>>
>>> This is explained in section 15.2 [1], refer below para:
>>> "The query might be suspended during execution. In any situation in
>>>
On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
> On 30 June 2017 at 05:14, Amit Kapila wrote:
>
>> This is explained in section 15.2 [1], refer below para:
>> "The query might be suspended during execution. In any situation in
>> which the system thinks that partial or incremental execution m
On 30 June 2017 at 05:14, Amit Kapila wrote:
> This is explained in section 15.2 [1], refer below para:
> "The query might be suspended during execution. In any situation in
> which the system thinks that partial or incremental execution might
> occur, no parallel plan is generated. For example,
On Fri, Jun 30, 2017 at 9:32 AM, Mark Dilger wrote:
>> On Jun 29, 2017, at 8:55 PM, Mark Dilger wrote:
>> Changing myfunc to create a temporary table, to execute the sql to populate
>> that temporary table, and to then loop through the temporary table's rows
>> fixes the problem. For the real-wo
> On Jun 29, 2017, at 8:55 PM, Mark Dilger wrote:
>
>
> Changing myfunc to create a temporary table, to execute the sql to populate
> that temporary table, and to then loop through the temporary table's rows
> fixes the problem. For the real-world example where I hit this, that single
> change
> On Jun 29, 2017, at 9:14 PM, Amit Kapila wrote:
>
> On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote:
>> Hackers,
>>
>> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
>> allow a parallel plan if a portal will be returned. This has the practical
>> consequence that
On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote:
> Hackers,
>
> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
> allow a parallel plan if a portal will be returned. This has the practical
> consequence that a common coding practice (at least for me) of doing
> somethin
Hackers,
In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
allow a parallel plan if a portal will be returned. This has the practical
consequence that a common coding practice (at least for me) of doing
something like:
create function myfunc(arg1 text, arg2 text) returns se
13 matches
Mail list logo
