On Wed, Jul 28, 2021 at 12:52 PM houzj.f...@fujitsu.com
wrote:
>
> > Consider below ways to allow the user to specify the parallel-safety option:
> >
> > (a)
> > CREATE TABLE table_name (...) PARALLEL DML { UNSAFE | RESTRICTED | SAFE }
> > ...
> > ALTER TABLE table_name PARALLEL DML { UNSAFE |
On July 27, 2021 1:14 PM Amit Kapila
> On Mon, Jul 26, 2021 at 8:33 PM Robert Haas
> wrote:
> >
> > On Sat, Jul 24, 2021 at 5:52 AM Amit Kapila
> wrote:
> > > I think for the consistency argument how about allowing users to
> > > specify a parallel-safety option for both partitioned and
> > >
On Tue, Jul 27, 2021 at 4:00 PM Greg Nancarrow wrote:
>
> On Tue, Jul 27, 2021 at 3:58 PM Dilip Kumar wrote:
> >
> > IMHO, for a non-partitioned table, we should be default allow the
> > parallel safely checking so that users don't have to set it for
> > individual tables, OTOH, I don't think
On Tue, Jul 27, 2021 at 3:58 PM Dilip Kumar wrote:
>
> IMHO, for a non-partitioned table, we should be default allow the
> parallel safely checking so that users don't have to set it for
> individual tables, OTOH, I don't think that there is any point in
> blocking the syntax for the
On Tue, Jul 27, 2021 at 11:28 AM Dilip Kumar wrote:
>
> On Tue, Jul 27, 2021 at 10:44 AM Amit Kapila wrote:
> >
> > On Mon, Jul 26, 2021 at 8:33 PM Robert Haas wrote:
> > Consider below ways to allow the user to specify the parallel-safety option:
> >
> > (a)
> > CREATE TABLE table_name (...)
On Tue, Jul 27, 2021 at 10:44 AM Amit Kapila wrote:
>
> On Mon, Jul 26, 2021 at 8:33 PM Robert Haas wrote:
> Consider below ways to allow the user to specify the parallel-safety option:
>
> (a)
> CREATE TABLE table_name (...) PARALLEL DML { UNSAFE | RESTRICTED | SAFE } ...
> ALTER TABLE
On Mon, Jul 26, 2021 at 8:33 PM Robert Haas wrote:
>
> On Sat, Jul 24, 2021 at 5:52 AM Amit Kapila wrote:
> > I think for the consistency argument how about allowing users to
> > specify a parallel-safety option for both partitioned and
> > non-partitioned relations but for non-partitioned
On Sat, Jul 24, 2021 at 5:52 AM Amit Kapila wrote:
> I think for the consistency argument how about allowing users to
> specify a parallel-safety option for both partitioned and
> non-partitioned relations but for non-partitioned relations if users
> didn't specify, it would be computed
On Fri, Jul 23, 2021 at 6:55 PM Robert Haas wrote:
>
> On Wed, Jul 21, 2021 at 11:55 PM Amit Kapila wrote:
> > I see here we have a mix of opinions from various people. Dilip seems
> > to be favoring the approach where we provide some option to the user
> > for partitioned tables and automatic
On Wed, Jul 21, 2021 at 11:55 PM Amit Kapila wrote:
> I see here we have a mix of opinions from various people. Dilip seems
> to be favoring the approach where we provide some option to the user
> for partitioned tables and automatic behavior for non-partitioned
> tables but he also seems to have
On Wed, Jul 21, 2021 at 12:30 AM Robert Haas wrote:
>
> On Sun, Jul 4, 2021 at 1:44 AM Dilip Kumar wrote:
> > In general, for the non-partitioned table, where we don't have much
> > overhead of checking the parallel safety and invalidation is also not
> > a big problem so I am tempted to provide
On Sun, Jul 4, 2021 at 1:44 AM Dilip Kumar wrote:
> In general, for the non-partitioned table, where we don't have much
> overhead of checking the parallel safety and invalidation is also not
> a big problem so I am tempted to provide an automatic parallel safety
> check. This would enable
On Sunday, July 4, 2021 1:44 PM Dilip Kumar wrote:
> On Fri, Jul 2, 2021 at 8:16 PM Robert Haas wrote:
> >
> > On Wed, Jun 30, 2021 at 11:46 PM Greg Nancarrow
> wrote:
> > > I personally think "(b) provide an option to the user to specify
> > > whether inserts can be parallelized on a relation"
On Fri, Jul 2, 2021 at 8:16 PM Robert Haas wrote:
>
> On Wed, Jun 30, 2021 at 11:46 PM Greg Nancarrow wrote:
> > I personally think "(b) provide an option to the user to specify
> > whether inserts can be parallelized on a relation" is the preferable
> > option.
> > There seems to be too many
On Wed, Jun 30, 2021 at 11:46 PM Greg Nancarrow wrote:
> I personally think "(b) provide an option to the user to specify
> whether inserts can be parallelized on a relation" is the preferable
> option.
> There seems to be too many issues with the alternative of trying to
> determine the
On Mon, Jun 28, 2021 at 7:51 PM Amit Kapila wrote:
>
> Among the above options, I would personally prefer (b) mainly because
> of the consistent handling for partition and non-partition table cases
> but I am fine with approach (a) as well if that is what other people
> feel is better.
>
>
On Mon, Jun 21, 2021 at 4:40 PM houzj.f...@fujitsu.com
wrote:
>
> To be honest, I didn't find a cheap way to invalidate partitioned table's
> parallel safety automatically.
>
I also don't see the feasibility for doing parallelism checks for
partitioned tables both because it is expensive due to
On Thu, Jun 24, 2021 at 1:38 PM Zhihong Yu wrote:
>
> How about walking the partition hierarchy bottom up, recording the parents
> but not taking the locks.
> Once top-most parent is found, take the locks in reverse order (top down) ?
>
Is it safe to walk up the partition hierarchy (to record
On Wed, Jun 23, 2021 at 8:10 PM Amit Kapila wrote:
> On Wed, Jun 16, 2021 at 6:10 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tuesday, June 15, 2021 10:01 PM Robert Haas
> wrote:
> > >
> > > Now, maybe it could be done, and I think that's worth a little more
> thought. For
> > > example,
On Wed, Jun 16, 2021 at 6:10 PM houzj.f...@fujitsu.com
wrote:
>
> On Tuesday, June 15, 2021 10:01 PM Robert Haas wrote:
> >
> > Now, maybe it could be done, and I think that's worth a little more
> > thought. For
> > example, perhaps whenever we invalidate a relation, we could also somehow
> >
On Wed, Jun 23, 2021 at 6:35 AM houzj.f...@fujitsu.com
wrote:
>
> On Tuesday, June 22, 2021 8:25 PM Amit Kapila wrote:
> > On Wed, Jun 16, 2021 at 8:57 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > I think the check of partition could be even more complicated if we
> > > need to check the
On Tuesday, June 22, 2021 8:25 PM Amit Kapila wrote:
> On Wed, Jun 16, 2021 at 8:57 AM houzj.f...@fujitsu.com
> wrote:
> >
> > I think the check of partition could be even more complicated if we
> > need to check the parallel safety of partition key expression. If user
> > directly insert into
On Wed, Jun 16, 2021 at 8:57 AM houzj.f...@fujitsu.com
wrote:
>
> I think the check of partition could be even more complicated if we need to
> check the parallel safety of partition key expression. If user directly
> insert into
> a partition, then we need invoke ExecPartitionCheck which will
On Monday, June 21, 2021 11:23 PM Robert Haas wrote:
> On Mon, Jun 21, 2021 at 12:56 AM Amit Kapila wrote:
> > Yeah, the session in which we are doing Alter Function won't be able
> > to lock it but it will wait for the AccessExclusiveLock on the rel to
> > be released because it will also try
On Mon, Jun 21, 2021 at 12:56 AM Amit Kapila wrote:
> I thought if we scan a system catalog using DirtySnapshot, then we
> should be able to find such a relation. But, if the system catalog is
> updated after our scan then surely we won't be able to see it and in
> that case, we won't be able to
On Wednesday, June 16, 2021 11:27 AM houzj.f...@fujitsu.com wrote:
> On Tuesday, June 15, 2021 10:01 PM Robert Haas wrote:
> > Just to be clear here, I don't think it really matters what we *want*
> > to do. I don't think it's reasonably *possible* to check all the
> > partitions, because we
On Thu, Jun 17, 2021 at 8:29 PM Robert Haas wrote:
>
> On Thu, Jun 17, 2021 at 4:54 AM Amit Kapila wrote:
> > I have responded about heavy-weight locking stuff in my next email [1]
> > and why I think the approach I mentioned will work. I don't deny that
> > I might be missing something here.
>
On Thu, Jun 17, 2021 at 4:54 AM Amit Kapila wrote:
> I have responded about heavy-weight locking stuff in my next email [1]
> and why I think the approach I mentioned will work. I don't deny that
> I might be missing something here.
>
> [1] -
>
On Wed, Jun 16, 2021 at 9:22 PM Robert Haas wrote:
>
> On Tue, Jun 15, 2021 at 10:41 AM Amit Kapila wrote:
> > > I don't think that finding the relation involved and registering an
> > > invalidation for the same will work properly. Suppose there is a
> > > concurrently-running transaction which
On Tue, Jun 15, 2021 at 10:41 AM Amit Kapila wrote:
> > I don't think that finding the relation involved and registering an
> > invalidation for the same will work properly. Suppose there is a
> > concurrently-running transaction which has created a new table and
> > attached a trigger function
On Tuesday, June 15, 2021 10:01 PM Robert Haas wrote:
> On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila wrote:
> > Okay, but I think if we go with your suggested model where whenever
> > there is a change in parallel-safety of any function, we need to send
> > the new invalidation then I think it
On Tue, Jun 15, 2021 at 8:11 PM Amit Kapila wrote:
>
> On Mon, Jun 14, 2021 at 9:08 PM Robert Haas wrote:
> >
> > On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila wrote:
> >
> > > Yeah, this could be one idea but I think even if we use pg_proc OID,
> > > we still need to check all the rel cache
On Tue, Jun 15, 2021 at 7:31 PM Robert Haas wrote:
>
> On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila wrote:
> > Okay, but I think if we go with your suggested model where whenever
> > there is a change in parallel-safety of any function, we need to send
> > the new invalidation then I think it
On Tuesday, June 15, 2021 10:01 PM Robert Haas wrote:
> On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila wrote:
> > Yeah, dealing with partitioned tables is tricky. I think if we don't
> > want to check upfront the parallel safety of all the partitions then
> > the other option as discussed could be
On Mon, Jun 14, 2021 at 9:08 PM Robert Haas wrote:
>
> On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila wrote:
>
> > Yeah, this could be one idea but I think even if we use pg_proc OID,
> > we still need to check all the rel cache entries to find which one
> > contains the invalidated OID and that
On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila wrote:
> Okay, but I think if we go with your suggested model where whenever
> there is a change in parallel-safety of any function, we need to send
> the new invalidation then I think it won't matter whether the function
> is associated with index
On Mon, Jun 14, 2021 at 9:08 PM Robert Haas wrote:
>
> On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila wrote:
> > Why do you think we don't need to check index AM functions? Say we
> > have an index expression that uses function and if its parallel safety
> > is changed then probably that also
On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila wrote:
> Why do you think we don't need to check index AM functions? Say we
> have an index expression that uses function and if its parallel safety
> is changed then probably that also impacts whether we can do insert in
> parallel. Because otherwise,
Amit Kapila writes:
> Why do you think we don't need to check index AM functions?
Primarily because index AMs and opclasses can only be defined by
superusers, and the superuser is assumed to know what she's doing.
More generally, we've never made any provisions for the properties
of index AMs
On Sat, Jun 12, 2021 at 1:56 AM Robert Haas wrote:
>
> On Fri, Jun 11, 2021 at 12:13 AM Amit Kapila wrote:
> > Do we invalidate relcache entry if someone changes say trigger or some
> > index AM function property via Alter Function (in our case from safe
> > to unsafe or vice-versa)?
On Fri, Jun 11, 2021 at 12:13 AM Amit Kapila wrote:
> Do we invalidate relcache entry if someone changes say trigger or some
> index AM function property via Alter Function (in our case from safe
> to unsafe or vice-versa)? Tsunakawa-San has mentioned this as the
> reason in his email [1] why we
On Thu, Jun 10, 2021 at 10:59 PM Robert Haas wrote:
>
> On Thu, Jun 10, 2021 at 12:54 AM Amit Kapila wrote:
> > Fair enough. So, I think there is a consensus to drop this patch and
> > if one wants then we can document these cases. Also, we don't want it
> > to enable parallelism for Inserts
On Thu, Jun 10, 2021 at 12:54 AM Amit Kapila wrote:
> Fair enough. So, I think there is a consensus to drop this patch and
> if one wants then we can document these cases. Also, we don't want it
> to enable parallelism for Inserts where we are trying to pursue the
> approach to have a flag in
On Wed, Jun 9, 2021 at 9:47 PM Robert Haas wrote:
>
> On Wed, Jun 9, 2021 at 2:43 AM Tom Lane wrote:
> > There are specific cases where there's a good reason to worry.
> > For example, if we assume blindly that domain_in() is parallel
> > safe, we will have cause to regret that. But I don't
On Wed, Jun 9, 2021 at 2:43 AM Tom Lane wrote:
> There are specific cases where there's a good reason to worry.
> For example, if we assume blindly that domain_in() is parallel
> safe, we will have cause to regret that. But I don't find that
> to be a reason why we need to lock down everything
"houzj.f...@fujitsu.com" writes:
> On Tuesday, June 8, 2021 10:51 PM Robert Haas
> wrote:
>> In my opinion, you're basically taking too pure a view of this. We're
>> not trying to create a system that does such a good job checking
>> parallel safety markings that nobody can possibly find a thing
On Tuesday, June 8, 2021 10:51 PM Robert Haas
> On Mon, Jun 7, 2021 at 11:33 PM Amit Kapila
> wrote:
> > Note the error is raised after applying the patch, without the patch,
> > the above won't show any error (error message could be improved here).
> > Such cases can lead to unpredictable
On Mon, Jun 7, 2021 at 11:33 PM Amit Kapila wrote:
> Note the error is raised after applying the patch, without the patch,
> the above won't show any error (error message could be improved here).
> Such cases can lead to unpredictable behavior without a patch because
> we won't be able to detect
On Mon, Jun 7, 2021 at 7:29 PM Robert Haas wrote:
>
> On Fri, Jun 4, 2021 at 6:17 AM Amit Kapila wrote:
> > Thoughts?
>
> As far as I can see, trying to error out at function call time if the
> function is parallel-safe doesn't fix any problem we have, and just
> makes the design of this part of
On Fri, Jun 4, 2021 at 6:17 AM Amit Kapila wrote:
> Thoughts?
As far as I can see, trying to error out at function call time if the
function is parallel-safe doesn't fix any problem we have, and just
makes the design of this part of the system less consistent with what
we've done elsewhere. For
On Tue, May 11, 2021 at 12:28 PM houzj.f...@fujitsu.com
wrote:
>
> Temporarily, Just in case someone want to take a look at the patch for the
> safety check.
>
I am not sure still there is a consensus on which cases exactly need
to be dealt with. Let me try to summarize the discussion and see
> > Sometimes this is actually quite useful. You might know that, while
> > the function is in general volatile, it is immutable in the particular
> > way that you are using it. Or, perhaps, you are using the volatile
> > function incidentally and it doesn't affect the output of your
> > function
From: Robert Haas
> On Wed, May 5, 2021 at 10:54 PM tsunakawa.ta...@fujitsu.com
> wrote:
> > As proposed in this thread and/or "Parallel INSERT SELECT take 2", we
> thought of detecting parallel unsafe function execution during SQL statement
> execution, instead of imposing much overhead to
On Thu, May 6, 2021 at 4:35 PM Robert Haas wrote:
>
> On Thu, May 6, 2021 at 3:00 AM Amit Kapila wrote:
> > The idea here is to check for parallel safety of functions at
> > someplace in the code during function invocation so that if we execute
> > any parallel unsafe/restricted function via
On Thu, May 6, 2021 at 5:26 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> Can anyone think of the need to check the parallel safety of built-in
> functions in the context of parallel INSERT SELECT? The planner already
> checks (or can check) the parallel safety of the SELECT part with
>
On Thu, May 6, 2021 at 3:00 AM Amit Kapila wrote:
> The idea here is to check for parallel safety of functions at
> someplace in the code during function invocation so that if we execute
> any parallel unsafe/restricted function via parallel worker then we
> error out. I think that is a good
On Wed, May 5, 2021 at 10:54 PM tsunakawa.ta...@fujitsu.com
wrote:
> (1) Is it better to get hardcoded function properties out of fmgr_builtins[]?
> It's little worth doing so or thinking about that. It's no business for
> users to change system objects, in this case system functions.
I don't
From: Robert Haas
> On Wed, Apr 28, 2021 at 9:42 PM houzj.f...@fujitsu.com
> wrote:
> > So, If we do not want to lock down the parallel safety of built-in
> > functions.
> > It seems we can try to fetch the proparallel from pg_proc for built-in
> > function
> > in fmgr_info_cxt_security too.
On Wed, May 5, 2021 at 7:39 PM Robert Haas wrote:
>
> On Tue, May 4, 2021 at 11:47 PM Greg Nancarrow wrote:
> > Problem is, for built-in functions, the changes are allowed, but for
> > some properties (like strict) the allowed changes don't actually take
> > effect (this is what Amit was
From: Robert Haas
> On Tue, May 4, 2021 at 11:47 PM Greg Nancarrow
> wrote:
> > Problem is, for built-in functions, the changes are allowed, but for
> > some properties (like strict) the allowed changes don't actually take
> > effect (this is what Amit was referring to - so why allow those
> >
On Tue, May 4, 2021 at 11:47 PM Greg Nancarrow wrote:
> Problem is, for built-in functions, the changes are allowed, but for
> some properties (like strict) the allowed changes don't actually take
> effect (this is what Amit was referring to - so why allow those
> changes?).
> It's because some
On Wed, May 5, 2021 at 5:09 AM Robert Haas wrote:
>
> On Fri, Apr 23, 2021 at 10:53 PM Amit Kapila wrote:
> > Isn't parallel safety also the C code property?
>
> > Also, if the strict property of built-in functions is fixed
> > internally, why we allow users to change it and is that of any help?
On Wed, Apr 28, 2021 at 9:42 PM houzj.f...@fujitsu.com
wrote:
> So, If we do not want to lock down the parallel safety of built-in functions.
> It seems we can try to fetch the proparallel from pg_proc for built-in
> function
> in fmgr_info_cxt_security too. To avoid recursive safety check when
On Fri, Apr 23, 2021 at 10:53 PM Amit Kapila wrote:
> Isn't parallel safety also the C code property?
In my opinion, yes.
> So, isn't it better to disallow changing parallel
> safety for built-in functions?
Superusers can do a lot of DML operations on the system catalogs that
are manifestly
> >>> I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> >>> that would "lock down the value" of the strict flag, wouldn't it?
>
> >> It does, but that's much more directly a property of the function's C
> >> code than parallel-safety is.
>
> > I'm not sure I agree with that,
On Sat, Apr 24, 2021 at 12:53 PM Amit Kapila wrote:
>
> On Fri, Apr 23, 2021 at 6:45 PM Tom Lane wrote:
> >
> > Greg Nancarrow writes:
> > > I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> > > that would "lock down the value" of the strict flag, wouldn't it?
> >
> > It
On Fri, Apr 23, 2021 at 6:45 PM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> > that would "lock down the value" of the strict flag, wouldn't it?
>
> It does, but that's much more directly a property of the function's
> C code
Robert Haas writes:
> On Fri, Apr 23, 2021 at 9:15 AM Tom Lane wrote:
>> Greg Nancarrow writes:
>>> I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
>>> that would "lock down the value" of the strict flag, wouldn't it?
>> It does, but that's much more directly a property of
On Fri, Apr 23, 2021 at 9:15 AM Tom Lane wrote:
> Greg Nancarrow writes:
> > I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> > that would "lock down the value" of the strict flag, wouldn't it?
>
> It does, but that's much more directly a property of the function's
> C code
Greg Nancarrow writes:
> I'm curious. The FmgrBuiltin struct includes the "strict" flag, so
> that would "lock down the value" of the strict flag, wouldn't it?
It does, but that's much more directly a property of the function's
C code than parallel-safety is.
regards,
On Wed, Apr 21, 2021 at 7:04 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Apr 21, 2021 at 8:12 AM tsunakawa.ta...@fujitsu.com
> > wrote:
> >> From: Tom Lane
> >>> [ raised eyebrow... ] I find it very hard to understand why that would
> >>> be necessary, or even a good idea.
>
> >
On Wed, Apr 21, 2021 at 12:22 PM Tom Lane wrote:
>
> "tsunakawa.ta...@fujitsu.com" writes:
> > From: Tom Lane
> >> No. You'd have to be superuser anyway to do that, and we're not in the
> >> habit of trying to put training wheels on superusers.
>
> > Understood. However, we may add the
From: Hou, Zhijie/侯 志杰
> For approach 1): I think it could result in infinite recursion.
>
> For example:
> If we first access one built-in function A which have not been cached,
> it need access the pg_proc, When accessing the pg_proc, it internally still
> need
> some built-in function B to
> Thank you, fmgr_info() looks like the best place to do the parallel safety
> check.
> Having a quick look at its callers, I didn't find any concerning place (of
> course,
> we can't be relieved until the regression test succeeds.) Also, with
> fmgr_info(),
> we don't have to find other
From: Hou, Zhijie/侯 志杰
> I agree that it's better to mark the function with correct parallel safety
> lable.
> Especially for the above functions which will be executed in parallel mode.
> It will be friendly to developer and user who is working on something related
> to
> parallel test.
>
>
From: Tom Lane
> Amit Kapila writes:
> > IIUC, the idea here is to check for parallel safety of functions at
> > someplace in the code during function invocation so that if we execute
> > any parallel unsafe/restricted function via parallel worker then we
> > error out. If so, isn't it possible
Amit Kapila writes:
> On Wed, Apr 21, 2021 at 8:12 AM tsunakawa.ta...@fujitsu.com
> wrote:
>> From: Tom Lane
>>> [ raised eyebrow... ] I find it very hard to understand why that would
>>> be necessary, or even a good idea.
> IIUC, the idea here is to check for parallel safety of functions at
On Wed, Apr 21, 2021 at 8:12 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Tom Lane
> > [ raised eyebrow... ] I find it very hard to understand why that would
> > be necessary, or even a good idea. Not least because there's no spare
> > room there; you'd have to incur a substantial
> I think we've found a few existing problems with handling the parallel safety
> of
> functions while doing an experiment. Could I hear your opinions on what we
> should do? I'd be willing to create and submit a patch to fix them.
>
> The experiment is to add a parallel safety check in
From: Tom Lane
> [ raised eyebrow... ] I find it very hard to understand why that would
> be necessary, or even a good idea. Not least because there's no spare
> room there; you'd have to incur a substantial enlargement of the
> array to add another flag. But also, that would indeed lock down
"tsunakawa.ta...@fujitsu.com" writes:
> From: Tom Lane
>> No. You'd have to be superuser anyway to do that, and we're not in the
>> habit of trying to put training wheels on superusers.
> Understood. However, we may add the parallel safety member in
> fmgr_builtins[] in another thread for
From: Tom Lane
> Bharath Rupireddy writes:
> > IMO, the reason for not checking the parallel safety of the support
> > functions is that the functions themselves can have whole lot of other
> > functions (can be nested as well) which might be quite hard to check
> > at the planning time. That is
Bharath Rupireddy writes:
> On Tue, Apr 20, 2021 at 2:23 PM tsunakawa.ta...@fujitsu.com
> wrote:
>> https://www.postgresql.org/docs/devel/xaggr.html
>>
>> "Worth noting also is that for an aggregate to be executed in parallel, the
>> aggregate itself must be marked PARALLEL SAFE. The
On Tue, Apr 20, 2021 at 2:23 PM tsunakawa.ta...@fujitsu.com
wrote:
> (2)
> I'm afraid the above phenomenon reveals that postgres overlooks parallel
> safety checks in some places. Specifically, we noticed the following:
>
> * User-defined aggregate
> CREATE AGGREGATE allows to specify parallel
84 matches
Mail list logo
