RE: Parallel copy

From: "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>
To: vignesh C <vignesh21(at)gmail(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-11-19 11:16:42
Message-ID: 341ed491c0c34c01ae4184d8c6065b2d@G08CNEXMBPEKD05.g08.fujitsu.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Vignesh,

I took a look at the v10 patch set. Here are some comments:

1.
+/*
+ * CheckExprParallelSafety
+ *
+ * Determine if where cluase and default expressions are parallel safe & do not
+ * have volatile expressions, return true if condition satisfies else return
+ * false.
+ */

'cluase' seems a typo.

2.
+ /*
+ * Make sure that no worker has consumed this element, if this
+ * line is spread across multiple data blocks, worker would have
+ * started processing, no need to change the state to
+ * LINE_LEADER_POPULATING in this case.
+ */
+ (void) pg_atomic_compare_exchange_u32(&lineInfo->line_state,
+ &current_line_state,
+ LINE_LEADER_POPULATED);
About the commect

+ * started processing, no need to change the state to
+ * LINE_LEADER_POPULATING in this case.

Does it means no need to change the state to LINE_LEADER_POPULATED ' here?

3.
+ * 3) only one worker should choose one line for processing, this is handled by
+ * using pg_atomic_compare_exchange_u32, worker will change the state to
+ * LINE_WORKER_PROCESSING only if line_state is LINE_LEADER_POPULATED.

In the latest patch, it will set the state to LINE_WORKER_PROCESSING if line_state is LINE_LEADER_POPULATED or LINE_LEADER_POPULATING.
So The comment here seems wrong.

4.
A suggestion for CacheLineInfo.

It use appendBinaryStringXXX to store the line in memory.
appendBinaryStringXXX will double the str memory when there is no enough spaces.

How about call enlargeStringInfo in advance, if we already know the whole line size?
It can avoid some memory waste and may impove a little performance.

Best regards,
houzj

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2020-11-19 11:27:29 Re: bad logging around broken restore_command
Previous Message Michael Paquier 2020-11-19 11:03:48 Re: Move OpenSSL random under USE_OPENSSL_RANDOM