Hi,
Based on the discussion in another thread[1], we plan to change the design like
the following:
allow 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 automatically? If t
On Tue, Jul 20, 2021 at 11:47 AM houzj.f...@fujitsu.com
wrote:
>
> Attach rebased patches.
>
Just letting you know that CRLFs are in the patch comments for the
0001 and 0003 patches.
(It doesn't affect patch application)
Regards,
Greg Nancarrow
Fujitsu Australia
On Thu, Jun 10, 2021 at 11:26 AM houzj.f...@fujitsu.com
wrote:
>
> Through further review and thanks for greg-san's suggestions,
> I attached a new version patchset with some minor change in 0001,0003 and
> 0004.
>
> 0001.
> * fix a typo in variable name.
> * add a TODO in patch comment about upd
On Mon, May 31, 2021 at 3:34 PM houzj.f...@fujitsu.com
wrote:
>
>
> Attaching v6 patchset.
> And I registered it in CF https://commitfest.postgresql.org/33/3143/,
> comments are welcome.
>
The latest patchset has some documentation updates. I'd like to
suggest a couple of documentation tweaks (th
On Mon, May 24, 2021 at 3:15 PM houzj.f...@fujitsu.com
wrote:
>
>
> Thanks for the comments and your descriptions looks good.
> Attaching v5 patchset with all these changes.
>
A few other minor things I noticed:
(1) error message wording when declaring a table SAFE for parallel DML
src/backend/
On Fri, May 14, 2021 at 6:24 PM houzj.f...@fujitsu.com
wrote:
>
> Thanks for the comments, I have posted new version patches with this change.
>
> > How about reorganisation of the patches like the following?
> > 0001: CREATE ALTER TABLE PARALLEL DML
> > 0002: parallel-SELECT-for-INSERT (planner c
> > > > > So, users need to check count(*) for this to determine
> > > > > parallel-safety? How about if we provide a wrapper function on
> > > > > top of this function or a separate function that returns char to
> > > > > indicate whether it is safe, unsafe, or restricted to perform a
> > > > > DM
On Tue, May 11, 2021 at 10:41 PM houzj.f...@fujitsu.com
wrote:
>
> Attaching new version patches with the following changes:
>
> 0001
> Add a new function pg_get_max_parallel_hazard('table_name') returns char('s',
> 'u', 'r')
> which indicate whether it is safe, unsafe, or restricted to perform a
On Tue, May 11, 2021 at 6:11 PM houzj.f...@fujitsu.com
wrote:
>
> > > > So, users need to check count(*) for this to determine
> > > > parallel-safety? How about if we provide a wrapper function on top
> > > > of this function or a separate function that returns char to
> > > > indicate whether it
> > > When the parallel safety of some of these objects is changed, it's costly
> > > to
> reflect it on the parallel safety of tables that depend on them. So, we
> don't do
> it. Instead, we provide a utility function
> pg_get_parallel_safety('table_name')
> that returns records of (objid, cl
On Mon, May 10, 2021 at 11:21 AM Amit Kapila wrote:
>
> Now, in the declarative approach, we can either go with whatever the
> user has mentioned or we can do some checks during DDL to determine
> the actual parallel-safety. I think even if try to determine
> parallel-safety during DDL it will be
On Mon, Apr 12, 2021 at 6:52 AM tsunakawa.ta...@fujitsu.com
wrote:
>
>
> SOLUTION TO (1)
>
>
> The candidate ideas are:
>
> 1) Caching the result of parallel-safety check
> The planner stores the result of checking parallel safety for each relation
> in re
On Wed, Apr 28, 2021 at 12:44 PM houzj.f...@fujitsu.com
wrote:
>
> 0003:
> 1) Temporarily, add the check of built-in function by adding a member for
> proparallel in FmgrBuiltin.
> To avoid enlarging FmgrBuiltin struct , change the existing bool members
> strict and and retset into
> one member
On Tue, Apr 27, 2021 at 8:12 AM Amit Kapila wrote:
> On Tue, Apr 27, 2021 at 7:45 AM Greg Nancarrow wrote:
> >
> > On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy
> > wrote:
> > >
> > >
> > > I still feel that why we shouldn't limit the declarative approach to
> > > only partitioned tables? A
On Tue, Apr 27, 2021 at 7:45 AM Greg Nancarrow wrote:
>
> On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy
> wrote:
> >
> >
> > I still feel that why we shouldn't limit the declarative approach to
> > only partitioned tables? And for normal tables, possibly with a
> > minimal cost(??), the serv
On Tue, Apr 27, 2021 at 7:39 AM houzj.f...@fujitsu.com
wrote:
> > I'm thinking that when users say ALTER TABLE partioned_table SET PARALLEL
> > TO 'safe';, we check all the partitions' and their associated objects'
> > parallel
> > safety? If all are parallel safe, then only we set partitioned_ta
On Tue, Apr 27, 2021 at 7:45 AM Greg Nancarrow wrote:
>
> On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy
> wrote:
> >
> >
> > I still feel that why we shouldn't limit the declarative approach to
> > only partitioned tables? And for normal tables, possibly with a
> > minimal cost(??), the serv
On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy
wrote:
>
>
> I still feel that why we shouldn't limit the declarative approach to
> only partitioned tables? And for normal tables, possibly with a
> minimal cost(??), the server can do the safety checking. I know this
> feels a little inconsisten
> > Currently, index expression and predicate are stored in text format.
> > We need to use stringToNode(expression/predicate) to parse it.
> > Some committers think doing this twice does not look good, unless we
> > found some ways to pass parsed info to the executor to avoid the second
> parse.
>
On Mon, Apr 26, 2021 at 4:56 PM houzj.f...@fujitsu.com
wrote:
> > > The parallel attributes in table means the parallel safety when user does
> > > some
> > data-modification operations on it.
> > > So, It only limit the use of parallel plan when using
> > > INSERT/UPDATE/DELETE.
> >
> > In that
> > The parallel attributes in table means the parallel safety when user does
> > some
> data-modification operations on it.
> > So, It only limit the use of parallel plan when using INSERT/UPDATE/DELETE.
>
> In that case, isn't it better to use the terminology "PARALLEL DML
> SAFE/UNSAFE/RESTRIC
On Mon, Apr 26, 2021 at 7:00 AM houzj.f...@fujitsu.com
wrote:
>
> > > Based on above, we plan to move forward with the apporache 2) (declarative
> > idea).
> >
> > IIUC, the declarative behaviour idea attributes parallel
> > safe/unsafe/restricted
> > tags to each table with default being the uns
On Mon, Apr 26, 2021 at 7:00 AM houzj.f...@fujitsu.com
wrote:
>
> > Instead, how about
> > postgres retries the query upon detecting the error that came from a
> > parallel
> > unsafe function during execution, disable parallelism and run the query? I
> > think
> > this kind of retry query featu
> > Based on above, we plan to move forward with the apporache 2) (declarative
> idea).
>
> IIUC, the declarative behaviour idea attributes parallel
> safe/unsafe/restricted
> tags to each table with default being the unsafe. Does it mean for a parallel
> unsafe table, no parallel selects, insert
On Thu, Apr 22, 2021 at 4:51 PM houzj.f...@fujitsu.com
wrote:
>
> > BACKGROUND
> >
> >
> > We want to realize parallel INSERT SELECT in the following steps:
> > 1) INSERT + parallel SELECT
> > 2) Parallel INSERT + parallel SELECT
> >
> > Below are example u
> > BACKGROUND
> >
> >
> > We want to realize parallel INSERT SELECT in the following steps:
> > 1) INSERT + parallel SELECT
> > 2) Parallel INSERT + parallel SELECT
> >
> > Below are example use cases. We don't expect high concurrency or an
> > empty data
> BACKGROUND
>
>
> We want to realize parallel INSERT SELECT in the following steps:
> 1) INSERT + parallel SELECT
> 2) Parallel INSERT + parallel SELECT
>
> Below are example use cases. We don't expect high concurrency or an empty
> data source.
> * Data
This is another try of [1].
BACKGROUND
We want to realize parallel INSERT SELECT in the following steps:
1) INSERT + parallel SELECT
2) Parallel INSERT + parallel SELECT
Below are example use cases. We don't expect high concurrency or an empty data
sou
28 matches
Mail list logo
