From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: Parallel copy |
Date: | 2020-12-09 10:41:16 |
Message-ID: | CALDaNm1ZhpYFNDG5xwkGNCqnJ3EkpV6z1NU=jdLm1XtVYagNMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 7, 2020 at 3:00 PM Hou, Zhijie <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> wrote:
>
> > Attached v11 patch has the fix for this, it also includes the changes to
> > rebase on top of head.
>
> Thanks for the explanation.
>
> I think there is still chances we can know the size.
>
> + * line_size will be set. Read the line_size again to be sure if it is
> + * completed or partial block.
> + */
> + dataSize = pg_atomic_read_u32(&lineInfo->line_size);
> + if (dataSize != -1)
> + {
>
> If I am not wrong, this seems the branch that procsssing the populated block.
> I think we can check the copiedSize here, if copiedSize == 0, that means
> Datasizes is the size of the whole line and in this case we can do the enlarge.
>
>
Yes this optimization can be done, I will handle this in the next patch set.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2020-12-09 10:48:33 | Re: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Seino Yuki | 2020-12-09 10:37:57 | Re: Feature improvement for pg_stat_statements |