From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, Luc Vlaming <luc(at)swarm64(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Zhihong Yu <zyu(at)yugabyte(dot)com>, vignesh C <vignesh21(at)gmail(dot)com> |
Subject: | Re: Parallel Inserts in CREATE TABLE AS |
Date: | 2021-01-04 12:47:48 |
Message-ID: | CALj2ACWth7mVQtqdYJwSn1mNmaHwxNE7YSYxRSLmfkqxRk+zmg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 31, 2020 at 10:53 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > How about naming like below more generically and placing them in
> > parallel.h so that it will also be used for refresh materialized view?
> >
> > +typedef enum ParallelInsertTupleCostOpt
> > +{
> > + PINS_SELECT_QUERY = 1 << 0, /* turn on this before planning */
> > + /*
> > + * Turn on this while planning for upper Gather path to ignore parallel
> > + * tuple cost in cost_gather.
> > + */
> > + PINS_CAN_IGN_TUP_COST = 1 << 1,
> > + /* Turn on this after the cost is ignored. */
> > + PINS_TUP_COST_IGNORED = 1 << 2
> >
> > My plan was to get the main design idea of pushing the dest receiver
> > to gather reviewed and once agreed, then I thought of making few
> > functions common and place them in parallel.h and parallel.c so that
> > they can be used for Parallel Inserts in REFRESH MATERIALIZED VIEW
> > because the same design idea can be applied there as well.
>
> I think instead of PINS_* we can name PARALLEL_INSERT_* other than
> that I am fine with the name.
Done.
>
> > For instance my thoughts are: add the below structures, functions and
> > other macros to parallel.h and parallel.c:
> > typedef enum ParallelInsertKind
> > {
> > PINS_UNDEF = 0,
> > PINS_CREATE_TABLE_AS,
> > PINS_REFRESH_MAT_VIEW
> > } ParallelInsertKind;
> >
> > typedef struct ParallelInsertCTASInfo
> > {
> > IntoClause *intoclause;
> > Oid objectid;
> > } ParallelInsertCTASInfo;
> >
> > typedef struct ParallelInsertRMVInfo
> > {
> > Oid objectid;
> > } ParallelInsertRMVInfo;
> >
> > ExecInitParallelPlan(PlanState *planstate, EState *estate,
> > Bitmapset *sendParams, int nworkers,
> > - int64 tuples_needed)
> > + int64 tuples_needed, ParallelInsertKind pinskind,
> > + void *pinsinfo)
> >
> > Change ExecParallelInsertInCTAS to
> >
> > +static void
> > +ExecParallelInsert(GatherState *node)
> > +{
> >
> > Change SetCTASParallelInsertState to
> > +void
> > +SetParallelInsertState(QueryDesc *queryDesc)
> >
> > Change IsParallelInsertionAllowedInCTAS to
> >
> > +bool
> > +IsParallelInsertionAllowed(ParallelInsertKind pinskind, IntoClause *into)
> > +{
> >
> > Thoughts?
> >
>
> I haven’t thought about these structures yet but yeah making them
> generic will be good.
Attaching v19 patch set. It has following changes: 1) generic code
which can easily be extended to parallel inserts in Refresh
Materialized View, parallelizing Copy To command 2) addressing the
review comments received so far.
Once these patches are reviewed and get to the commit stage, I can
post a separate patch (probably in a separate thread) for parallel
inserts in Refresh Materialized View based on this patch set.
Please review the v19 patch set further.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
v19-0001-Parallel-Inserts-in-CREATE-TABLE-AS.patch | application/octet-stream | 36.5 KB |
v19-0002-Tuple-Cost-Adjustment-for-Parallel-Inserts-in-CTAS.patch | application/octet-stream | 15.4 KB |
v19-0003-Tests-And-Docs-For-Parallel-Inserts-in-CTAS.patch | application/octet-stream | 29.8 KB |
v19-0004-Enable-CTAS-Parallel-Inserts-For-Append.patch | application/octet-stream | 46.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | 赵锐 | 2021-01-04 13:04:51 | [Bug Fix] Logical replication on partition table is very slow and CPU is 99% |
Previous Message | Heikki Linnakangas | 2021-01-04 12:42:27 | Re: pg_rewind restore_command issue in PG12 |