On Thu, Sep 22, 2016 at 7:32 PM, Robert Haas wrote:
> On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila wrote:
>> I think for certain cases like into clause, the rows passed will be
>> equal to actual number of rows, otherwise it will generate error. So
>> we can pass that information in executor lay
On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila wrote:
> I think for certain cases like into clause, the rows passed will be
> equal to actual number of rows, otherwise it will generate error. So
> we can pass that information in executor layer. Another kind of cases
> which are worth considering a
On Tue, Sep 20, 2016 at 8:31 PM, Robert Haas wrote:
> On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila wrote:
>> I think here point is that for any case where there is count of rows
>> to be selected, we disable parallelism. There are many genuine cases
>> like select count(*) into cnt ... which wil
On Tue, Sep 20, 2016 at 10:58 AM, Tom Lane wrote:
> Maybe it would be better to fix the rule against workers
> invoking their own parallel queries.
That rule does have the advantage of preventing us from having one
user backend launch N^2 workers. I don't think it would be that much
work to fix
On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila wrote:
> I think here point is that for any case where there is count of rows
> to be selected, we disable parallelism. There are many genuine cases
> like select count(*) into cnt ... which will run to completion, but as
> plpgsql passes row count to
Amit Kapila writes:
> On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas wrote:
>> However, I think the chances of supporting parallel query for queries
>> not executed to completion any time in the near future are very poor.
> I think here point is that for any case where there is count of rows
> to
On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas wrote:
> On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila wrote:
>> In general, I think we should support the cases as required (or
>> written) by you from plpgsql or sql functions. We need more work to
>> support such cases. There are probably two ways
On 18.09.2016 06:54, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov wrote:
On 16.09.2016 16:50, Amit Kapila wrote:
Can you try by setting force_parallel_mode = off;? I think it is
sending the whole function execution to worker due to
force_parallel_mode.
No changes:
On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila wrote:
> In general, I think we should support the cases as required (or
> written) by you from plpgsql or sql functions. We need more work to
> support such cases. There are probably two ways of supporting such
> cases, we can build some intelligence
On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov wrote:
>
> On 16.09.2016 16:50, Amit Kapila wrote:
>>
>>
>> Can you try by setting force_parallel_mode = off;? I think it is
>> sending the whole function execution to worker due to
>> force_parallel_mode.
>>
>>
>
> No changes:
>
Okay, it just skippe
On 16.09.2016 16:50, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 6:57 PM, Alex Ignatov wrote:
No it doesn't.
Paralleling neither sql function nor plpgsql:
Here is example :
ipdr=> show max_worker_processes ;
max_worker_processes
--
128
(1 row)
ipdr=> set max_parallel_work
On Fri, Sep 16, 2016 at 6:57 PM, Alex Ignatov wrote:
> No it doesn't.
> Paralleling neither sql function nor plpgsql:
> Here is example :
>
> ipdr=> show max_worker_processes ;
> max_worker_processes
> --
> 128
> (1 row)
> ipdr=> set max_parallel_workers_per_gather to 128;
>
No it doesn't.
Paralleling neither sql function nor plpgsql:
Here is example :
ipdr=> show max_worker_processes ;
max_worker_processes
--
128
(1 row)
ipdr=> set max_parallel_workers_per_gather to 128;
SET
ipdr=> set force_parallel_mode=on;
SET
ipdr=> set min_parallel_relatio
On Thu, Sep 15, 2016 at 9:15 PM, Alex Ignatov wrote:
> Hello!
> Does parallel secscan works in plpgsql?
>
Parallel seq scan is a query optimization that will work independent
of the source of the query - i.e whether it comes directly from a
client or a procedural language like plpgsql. So, I gues
Hello!
Does parallel secscan works in plpgsql?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hac
15 matches
Mail list logo
