Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-10-02 23:24:30，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Sun, Oct 1, 2017 at 8:27 PM, chenhj <chjis...@163.com> wrote:





Now, this patch looks good for me.  It applies cleanly, builds cleanly, passes 
regression tests, new functionality is covered by regression tests.  Code is OK 
for me and docs too.


I'm marking this patch as "Ready for committer".  BTW, authors field in the 
commitfest app is empty (https://commitfest.postgresql.org/15/1302/).  Please, 
put your name there.


I hope this patch will be committed during 2017-11 commitfest.  Be ready to 
rebase this patch if needed.  Thank you for your work.


I had filled the authors field of this patch in commitfest, and will rebase 
this patch if needed. Thank you for your help!


--
Best Regards,
Chen Huajun

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On  2017-10-01 04:09:19,"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Sat, Sep 30, 2017 at 8:18 PM, chenhj <chjis...@163.com> wrote:

On 2017-09-30 02:17:54，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:


Great.  Now code of this patch looks good for me.
However, we forgot about documentation.


  
   The result is equivalent to replacing the target data directory with the
   source one. Only changed blocks from relation files are copied;
   all other files are copied in full, including configuration files. The
   advantage of pg_rewind over taking a new base backup, or
   tools like rsync, is that pg_rewind does
   not require reading through unchanged blocks in the cluster. This makes
   it a lot faster when the database is large and only a small
   fraction of blocks differ between the clusters.
  


At least, this paragraph need to be adjusted, because it states whose files are 
copied.  And probably latter paragraphs whose state about WAL files.






Your are rigth.
I wrote a draft as following, but i'm afraid whether the english statement is 
accurate.


I'm not native english speaker too :(


Only the WAL files between the point of divergence and the current WAL insert 
location of the source server are copied, *for* other WAL files are useless for 
the target server. 


I'm not sure about this usage of word *for*.  For me, it probably should be 
just removed.  Rest of changes looks good for me.  Please, integrate them into 
the patch.




I had removed the *for* , Pleae check the new patch again.


---
Best Regards,
Chen Huajun

pg_rewind_wal_copy_reduce_v8.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-30 02:17:54，"Alexander Korotkov"  wrote:


Great.  Now code of this patch looks good for me.
However, we forgot about documentation.


  
   The result is equivalent to replacing the target data directory with the
   source one. Only changed blocks from relation files are copied;
   all other files are copied in full, including configuration files. The
   advantage of pg_rewind over taking a new base backup, or
   tools like rsync, is that pg_rewind does
   not require reading through unchanged blocks in the cluster. This makes
   it a lot faster when the database is large and only a small
   fraction of blocks differ between the clusters.
  


At least, this paragraph need to be adjusted, because it states whose files are 
copied.  And probably latter paragraphs whose state about WAL files.






Your are rigth.
I wrote a draft as following, but i'm afraid whether the english statement is 
accurate.


--
diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index d5430d4..bcd094b 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -50,9 +50,12 @@ PostgreSQL documentation
   
The result is equivalent to replacing the target data directory with the
source one. Only changed blocks from relation files are copied;
-   all other files are copied in full, including configuration files. The
-   advantage of pg_rewind over taking a new base backup, or
-   tools like rsync, is that pg_rewind does
+   all other files except WAL are copied in full, including configuration
+   files. Only the WAL files between the point of divergence and the current
+   WAL insert location of the source server are copied, for other WAL files
+   are useless for the target server. The advantage of
+   pg_rewind over taking a new base backup, or tools
+   like rsync, is that pg_rewind does
not require reading through unchanged blocks in the cluster. This makes
it a lot faster when the database is large and only a small
fraction of blocks differ between the clusters.
@@ -231,7 +234,7 @@ PostgreSQL documentation
  
   Copy all other files such as pg_xact and
   configuration files from the source cluster to the target cluster
-  (everything except the relation files).
+  (everything except the relation files and some WAL files).
  
 
 


--
Best Regars,
Chen Huajun

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-30 00:53:31，"chenhj" <chjis...@163.com> wrote:

On 2017-09-29 19:29:40，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Fri, Sep 29, 2017 at 10:07 AM, chenhj <chjis...@163.com> wrote:




OK.  That makes sense.  Thank you for the explanation.


I still have some minor comments.
 
/*
+* Save the WAL filenames of the divergence and the current WAL insert
+* location of the source server. Later only the WAL files between those
+* would be copied to the target data directory.



Comment is outdated.  We don't save filenames anymore, now we save segment 
numbers.
 
+* Note:The later generated WAL files in the source server before the end
+* of the copy of the data files must be made available when the target
+* server is started. This can be done by configuring the target server as
+* a standby of the source server.
+*/


You miss space after "Note:".  Also, it seems reasonable for me to leave empty 
line before "Note:".


# Setup parameter for WAL reclaim 


Parameter*s*, because you're setting up multiple of them.


# The accuracy of imodification from pg_ls_waldir() is seconds, so sleep one 
seconds


One second without "s".


Also, please check empty lines in 006_wal_copy.pl to be just empty lines 
without tabs.


Thanks for your comments, i had fix above problems.
And also add several line breaks at long line in 006_wal_copy.pl
Please check this patch again.


Sorry, patch v6 did not remove tabs in two empty lines, please use the new one.


Best Regards,
Chen Huajun

pg_rewind_wal_copy_reduce_v7.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-29 19:29:40，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Fri, Sep 29, 2017 at 10:07 AM, chenhj <chjis...@163.com> wrote:




OK.  That makes sense.  Thank you for the explanation.


I still have some minor comments.
 
/*
+* Save the WAL filenames of the divergence and the current WAL insert
+* location of the source server. Later only the WAL files between those
+* would be copied to the target data directory.



Comment is outdated.  We don't save filenames anymore, now we save segment 
numbers.
 
+* Note:The later generated WAL files in the source server before the end
+* of the copy of the data files must be made available when the target
+* server is started. This can be done by configuring the target server as
+* a standby of the source server.
+*/


You miss space after "Note:".  Also, it seems reasonable for me to leave empty 
line before "Note:".


# Setup parameter for WAL reclaim 


Parameter*s*, because you're setting up multiple of them.


# The accuracy of imodification from pg_ls_waldir() is seconds, so sleep one 
seconds


One second without "s".


Also, please check empty lines in 006_wal_copy.pl to be just empty lines 
without tabs.


Thanks for your comments, i had fix above problems.
And also add several line breaks at long line in 006_wal_copy.pl
Please check this patch again.


--
Best Regards
Chen Huajun

pg_rewind_wal_copy_reduce_v6.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-29 05:31:51, "Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Thu, Sep 28, 2017 at 10:52 PM, chenhj <chjis...@163.com> wrote:

On 2017-09-29 00:43:18，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Thu, Sep 28, 2017 at 6:44 PM, chenhj <chjis...@163.com> wrote:

On 2017-09-28 01:29:29，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

It appears that your patch conflicts with fc49e24f.  Please, rebase it.



Yes, i had rebased it, Please check the new patch. 


Good, now it applies cleanly.


else if (strncmp(path, XLOGDIR"/", strlen(XLOGDIR"/")) == 0 &&
 IsXLogFileName(path + strlen(XLOGDIR"/")) &&
 (strcmp(path + strlen(XLOGDIR"/") + 8, divergence_wal_filename + 8) < 0 ||
  strcmp(path + strlen(XLOGDIR"/") + 8, last_source_wal_filename + 8) > 0))


According to our conding style, you should leave a space betwen XLOGDIF and "/".
Also, you do a trick by comparison xlog segment numbers using strcmp().  It's 
nice, but I would prefer seeing XLogFromFileName() here.  It would improve code 
readability and be less error prone during further modifications.


Thanks for advice!
I had modified it.


OK. Patch becomes better.
I also have more general question.  Why do we need upper bound for segment 
number (last_source_segno)?  I understand the purpose of lower bound 
(divergence_segno) which save us from copying extra WAL files, but what is 
upper bound for?  As I understood, we anyway need to replay most recent WAL 
records to reach consistent state after pg_rewind.  I propose to remove 
last_source_segno unless I'm missing something.


Thanks for relay!
When checkpoint occurs, some old WAL files will be renamed as future WAL files 
for later use.
The upper bound for segment number (last_source_segno) is used to avoid copying 
these extra WAL files.


When the parameter max_wal_size or max_min_size is large,these may be many 
renamed old WAL files for reused.


For example, I have just looked at one of our production systems (max_wal_size 
= 64GB, min_wal_size = 2GB), 
the total size of WALs is about 30GB, and contains about 4GB renamed old WAL 
files.


[postgres@hostxxx pg_xlog]$ ll
...
-rw--- 1 postgres postgres 16777216 Sep 29 14:05 00010BCF0078
-rw--- 1 postgres postgres 16777216 Sep 29 14:05 00010BCF0079
-rw--- 1 postgres postgres 16777216 Sep 29 14:05 00010BCF007A
-rw--- 1 postgres postgres 16777216 Sep 29 14:05 00010BCF007B
-rw--- 1 postgres postgres 16777216 Sep 29 14:05 00010BCF007C
-rw--- 1 postgres postgres 16777216 Sep 29 14:05 00010BCF007D
-rw--- 1 postgres postgres 16777216 Sep 29 11:22 00010BCF007E 
//after this, there are about 4GB WALs for reuse
-rw--- 1 postgres postgres 16777216 Sep 29 11:08 00010BCF007F
-rw--- 1 postgres postgres 16777216 Sep 29 11:06 00010BCF0080
-rw--- 1 postgres postgres 16777216 Sep 29 12:05 00010BCF0081
-rw--- 1 postgres postgres 16777216 Sep 29 11:28 00010BCF0082
-rw--- 1 postgres postgres 16777216 Sep 29 11:06 00010BCF0083
...


-
Best Regards,
Chen Huajun

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-29 00:43:18，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Thu, Sep 28, 2017 at 6:44 PM, chenhj <chjis...@163.com> wrote:

On 2017-09-28 01:29:29，"Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

It appears that your patch conflicts with fc49e24f.  Please, rebase it.



Yes, i had rebased it, Please check the new patch. 


Good, now it applies cleanly.


else if (strncmp(path, XLOGDIR"/", strlen(XLOGDIR"/")) == 0 &&
 IsXLogFileName(path + strlen(XLOGDIR"/")) &&
 (strcmp(path + strlen(XLOGDIR"/") + 8, divergence_wal_filename + 8) < 0 ||
  strcmp(path + strlen(XLOGDIR"/") + 8, last_source_wal_filename + 8) > 0))


According to our conding style, you should leave a space betwen XLOGDIF and "/".
Also, you do a trick by comparison xlog segment numbers using strcmp().  It's 
nice, but I would prefer seeing XLogFromFileName() here.  It would improve code 
readability and be less error prone during further modifications.




--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


Thanks for advice!
I had modified it.


-
Best Regards,
Chen Huajun






pg_rewind_wal_copy_reduce_v5.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-28 01:29:29，"Alexander Korotkov"  wrote:





It appears that your patch conflicts with fc49e24f.  Please, rebase it.


--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com

The Russian Postgres Company 


Yes, i had rebased it, Please check the new patch. 


--
Best Regards,
Chen Huajun







pg_rewind_wal_copy_reduce_v4.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

On 2017-09-23 01:59:0, "Alexander Korotkov" <a.korot...@postgrespro.ru> wrote:

On Fri, Sep 22, 2017 at 7:16 PM, chenhj <chjis...@163.com> wrote:

This is the new pacth with TAP test and use Macro XLOGDIR.


Good.  I took a quick look over the patch.
Why do you need master_query(), standby_query() and run_query() in 
RewindTest.pm?
You can do just $node_master->safe_psql() and $node_slave->safe_psql() instead.


Ooh, i did not notice that function.Thank you for your advice!
 
---
Regards,
Chen Huajun

pg_rewind_wal_copy_reduce_v3.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

Hi


This is the new pacth with TAP test and use Macro XLOGDIR.
And i had add this patch to the commitfest, 
https://commitfest.postgresql.org/15/1302/


--
Best Regards,
Chen Huajun

pg_rewind_wal_copy_reduce_v2.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

At 2017-09-17 08:33:33, "Michael Paquier" <michael.paqu...@gmail.com> wrote:
>On Sun, Sep 17, 2017 at 3:19 AM, Alexander Korotkov
><a.korot...@postgrespro.ru> wrote:
>> Hi!
>>
>> On Sat, Sep 16, 2017 at 5:56 PM, chenhj <chjis...@163.com> wrote:
>>>
>>> This patch optimizes the above mentioned issues, as follows:
>>> 1. In the target data directory, do not delete the WAL files before the
>>> divergence.
>>> 2. When copying files from the source server, do not copy the WAL files
>>> before the divergence and the WAL files after the current WAL insert
>>> localtion.
>>
>>
>> Looks like cool optimization for me.  Please, add this patch to the next
>> commitfest.
>
>Agreed.
>
>> Do you think this patch should modify pg_rewind tap tests too?  It would be
>> nice to make WAL files fetching more covered by tap tests.  In particular,
>> new tests may generate more WAL files and make sure that pg_rewind fetches
>> only required files among them.
>
>This looks mandatory to me. Using pg_switch_wal() and a minimum amount
>of WAL generated you could just make the set of WAL segments skipped
>minimal data.
>
>I have not checked in details, but I think that the positions where
>you are applying the filters are using the right approach.
>
>! !(strncmp(path, "pg_wal", 6) == 0 && IsXLogFileName(path + 7) &&
>Please use XLOGDIR here.
>-- 
>Michael
>

Thanks, I will use XLOGDIR and add TAP tests later.


--
Chen Huajun 

[HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

[chenhj]

Hi all,


Currently, pg_rewind copies all WAL files from the source server, whether or 
not they are needed.
In some circumstances, will bring a lot of unnecessary network and disk IO 
consumption, and also increase the execution time of pg_rewind.
Such as when wal_keep_segments or max_wal_size is large.


According to pg_rewind's processing logic, only need to copy the WAL after the 
divergence from the source server. 
The WAL before the divergence must already exists on the target server.
Also, there is no need to copy WALs that have been recovered.


This patch optimizes the above mentioned issues, as follows:
1. In the target data directory, do not delete the WAL files before the 
divergence.
2. When copying files from the source server, do not copy the WAL files before 
the divergence and the WAL files after the current WAL insert localtion.


Note:
The "current WAL insert localtion" above is obtained before copying data files. 
If a runing PostgreSQL server is used as the source server, the newly generated 
WAL files during pg_rewind running will not be copied to 
the target data directory.
However, in this case the target server is typically used as a standby of the 
source server after pg_rewind is executed, so these WAL files will be copied 
via streaming replication later.


--
Best regards
Chen Huajun

pg_rewind_wal_copy_reduce.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH:do not set Win32 server-side socket buffer size on windows 2012

[chenhj]

2015-07-03 16:49:44,David Rowley david.row...@2ndquadrant.com wrote：

I'm wondering what the original test setup was. I'm assuming psql and postgres 
both running on separate windows machines?


I've tested the patch just connecting to a database running on localhost and 
I'm not getting much of a speedup. Perhaps 1%, if that's not noise. I don't 
have enough hardware here to have client and server on separate machines, at 
least not with a stable network that goes through copper.




My original test environments is as the following


Environment1:
Server:Windows 2012(x64)
  The host is a VM in a private cloud
Client:RHEL6(x64)
 The host is another VM in the same private cloud
Network:1Gbit LAN


Environment2:
Server:Windows 2012(x64)
  The host is a VM in a private cloud
Client:Windows 7(x64)
  The host is a physical machine(in fact it is My PC).
Network:1Gbit LAN


This Patch should only can speedup the environment which satisfy the following 
conditions.
1. The OS of the server is Windows 2012 or Win8(but i only tested it in Windows 
2012).
2. The client and the server is separate machines.
3. The performance bottleneck is network throughput.
4. The utilization rate of network bandwidth is not full(such as only 50% or 
lower).


Best Regards
Chen Huajun

Re: [HACKERS] PATCH:do not set Win32 server-side socket buffer size on windows 2012

[chenhj]

At 2015-04-10 20:00:35, Michael Paquier michael.paqu...@gmail.com wrote:

Interesting. I think that for the time being you should add it to the
next commit fest to target an integration in 9.6 as these days we are
busy wrapping up the last commit fest of 9.5:
https://commitfest.postgresql.org/5/



I had add it to the commit fest.
https://commitfest.postgresql.org/5/212/

Best Regards,
Chen Huajun 

Re: [HACKERS] OOM-killer issue when updating a inheritance table which has large number of child tables

[chenhj]

At the moment, partitioning into thousands of tables is not supported.
Thank you for your reply. And thanks Tom Lane and Stephen Frost！


The following(with createsql.sql and update.sql as attachment) is my complete 
test case. And i reproduced this problem in PostgreSQL 9.4.1 . 


1)create table and data
createdb db1000
psql -q -v total=1000 -v pnum=1000 -f createsql.sql |psql db1000
psql -c insert into maintb values(1,'abcde12345') db1000


2)update the parent table with one connection, 955MB memory has been used.
[chenhj@node2 part]$ pgbench -c 1 -n -T 10 -r -f update.sql db1000;
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
duration: 10 s
number of transactions actually processed: 20
tps = 1.933407 (including connections establishing)
tps = 1.934807 (excluding connections establishing)
statement latencies in milliseconds:
516.836800update maintb set name = 'a12345' where id=1;




part of output from top when runing pgbench:
...
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
   
22537 chenhj20   0  955m 667m  11m R 99.4 33.3   0:06.12 postgres  




3)update the parent table with ten connections simultaneously, OOM ocurrs.
Now,to run pgbench 955MB * 10 memory are needed,but my machine only has 2GB 
physical memory and 4GB Swap.


[chenhj@node2 part]$ pgbench -c 10 -n -T 2 -r -f update.sql db1000;
Client 0 aborted in state 0. Probably the backend died while processing.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
Client 3 aborted in state 0. Probably the backend died while processing.
Client 6 aborted in state 0. Probably the backend died while processing.
Client 1 aborted in state 0. Probably the backend died while processing.
Client 5 aborted in state 0. Probably the backend died while processing.
Client 8 aborted in state 0. Probably the backend died while processing.
Client 9 aborted in state 0. Probably the backend died while processing.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
Client 7 aborted in state 0. Probably the backend died while processing.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
Client 4 aborted in state 0. Probably the backend died

[HACKERS] OOM-killer issue when updating a inheritance table which has large number of child tables

[chenhj]

Hi


In my test(PG9.3.4), i found when update a parent table which has a large 
number of child tables, the execute plan will consume lots of memory. And 
possibly cause OOM.


For example:
 create table maintb(id int,name char(10));
 create table childtb_1 (CHECK ( id BETWEEN 1 AND 200)) inherits(maintb);
 create table childtb_2 (CHECK ( id BETWEEN 201 AND 400)) inherits(maintb);
 ...
 create table childtb_n ...




When there are 100 child tables,the following update statement will consume 
about 8MB memory when invoking pg_plan_queries()
update maintb set name = 'a12345' where id=1;


And, when there are 1000 child tables,the same update statement will consume 
717MB memory when invoking pg_plan_queries().


Does this a known problem, and could that be improved in the future?


BTW:
The following comment is according my debuging when update the parent table 
with 1000 child tables
src/backend/optimizer/plan/planner.c
static Plan *
inheritance_planner(PlannerInfo *root)
{
...
foreach(lc, root-append_rel_list)//### loop 1001 time
{
...
subroot.parse = (Query *)
adjust_appendrel_attrs(root,
 (Node *) parse,
 appinfo);//### allocate about 300KB memory a 
time.


...
subroot.append_rel_list = (List *) 
copyObject(root-append_rel_list);//### allocate about 400KB memory a time.


...
}
...
}


Best Regards
Chen Huajun