| From: | Michael Paquier <michael(at)paquier(dot)xyz> | 
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> | 
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: move PartitionBoundInfo creation code | 
| Date: | 2018-11-05 07:21:03 | 
| Message-ID: | 20181105072103.GE1718@paquier.xyz | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
> Done a few moments ago. :)
From the file size this move is actually negative.  From what I can see
partcache decreases to 400 lines, while partbounds increases to 3k
lines.
There are a couple of things that this patch is doing:
1) Move the functions comparing two bounds into partbounds.c.
2) Remove the chunk in charge of building PartitionBoundData into
partbounds.c for each method: list, hash and values.
From what I can see, this patch brings actually more confusion by doing
more things than just building all the PartitionBound structures as it
fills in each structure and then builds a mapping which is used to save
each partition OID into the correct mapping position.  Wouldn't it move
on with a logic without this mapping so as the partition OIDs are
directly part of PartitionBound?  It looks wrong to me to have
build_partition_boundinfo create not only partdesc->boundinfo but also
partdesc->oids, and the new routine is here to fill in data for the
former, not the latter.
The first phase building the bounds should switch to a switch/case like
the second phase.
PartitionHashBound & friends can become structures local to
partbounds.c as they are used only there.
To be more consistent with all the other routines, like
partition_bounds_equal/copy, wouldn't it be better to call the new
routine partition_bounds_build or partition_bounds_create?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-11-05 07:28:09 | Re: Strange failure in LWLock on skink in REL9_5_STABLE | 
| Previous Message | Amit Langote | 2018-11-05 07:17:13 | Re: Speeding up INSERTs and UPDATEs to partitioned tables |