Re: [HACKERS] Runtime Partition Pruning

ab.ntt.co.jp Tested on commit: 9b9cb3c4534d717c1c95758670198ebbf8a20af2 -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company 0001-Implement-runtime-partiton-pruning.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] path toward faster partition pruning

Hello, On Wed, Oct 25, 2017 at 1:07 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/10/25 15:47, Amit Langote wrote: >> On 2017/10/24 1:38, Beena Emerson wrote: >>> I had noticed this and also that this crash: >>> >>> tprt PARTITION B

Re: [HACKERS] path toward faster partition pruning

Hello Amit, Thanks for the updated patches On Wed, Oct 25, 2017 at 1:07 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/10/25 15:47, Amit Langote wrote: >> On 2017/10/24 1:38, Beena Emerson wrote: >>> I had noticed this and also that this crash: >>

Re: [HACKERS] path toward faster partition pruning

; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !> -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Runtime Partition Pruning

Append (cost=0.00..1736.55 rows=2 width=8) -> Seq Scan on tprt_1 (cost=0.00..849.15 rows=16724 width=8) Filter: (col1 < $1) -> Seq Scan on tprt_2 (cost=0.00..849.15 rows=16724 width=8) Filter: (col1 < $1) (5 rows) -- Beena Emerson EnterpriseDB: http://w

Re: [HACKERS] Default Partition for Range

%2BAuYkdTPY9cLWWLjxt_k4SXue3eieAr%2Bg%40mail.gmail.com Thank you, Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Default Partition for Range

Hello, On Thu, Aug 24, 2017 at 3:08 PM, Jeevan Ladhe <jeevan.la...@enterprisedb.com> wrote: > Hi Beena, > > > On Tue, Aug 22, 2017 at 5:22 PM, Beena Emerson <memissemer...@gmail.com> > wrote: >> >> On Tue, Aug 22, 2017 at 4:20 PM, Beena Emerson <memisse

Re: [HACKERS] Default Partition for Range

On Tue, Aug 22, 2017 at 4:20 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Hi Jeevan, > > On Tue, Aug 22, 2017 at 7:53 AM, Jeevan Ladhe > <jeevan.la...@enterprisedb.com> wrote: >> >> >> 4. >> static List * >> -get_qua

Re: [HACKERS] Default Partition for Range

Hi Jeevan, On Tue, Aug 22, 2017 at 7:53 AM, Jeevan Ladhe <jeevan.la...@enterprisedb.com> wrote: > > Hi Beena, > > On Thu, Aug 17, 2017 at 4:59 PM, Beena Emerson <memissemer...@gmail.com> > wrote: >> >> PFA the patch rebased over v25 patches of default list

Re: [HACKERS] Default Partition for Range

PFA the patch rebased over v25 patches of default list partition [1] [1] https://www.postgresql.org/message-id/CAOgcT0NwqnavYtu-QM-DAZ6N%3DwTiqKgy83WwtO2x94LSLZ1-Sw%40mail.gmail.com -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Default Partition for Range

://www.postgresql.org/message-id/CAOgcT0OVwDu%2BbeChWb5R5s6rfKLCiWcZT5617hqu7T3GdA1hAw%40mail.gmail.com -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company default_range_partition_v11.patch Description: Binary data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] expanding inheritance in partition bound order

be used uninitialized in this function [-Wmaybe-uninitialized] next_ptinfo->parentid != ptinfo->parentid) -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Default Partition for Range

minated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > Thank you for testing. It seems I made a mistake in the assert condition. I have corrected it in this patch. Thank you, Beena Emerson Ent

Re: [HACKERS] Default Partition for Range

On Fri, Aug 4, 2017 at 7:48 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jul 31, 2017 at 8:28 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > > Why do we need to introduce PARTITION_RANGE_DATUM_DEFAULT at all? It > seems to me that the handling

Re: [HACKERS] Default Partition for Range

org/message-id/CAOgcT0OVwDu%2BbeChWb5R5s6rfKLCiWcZT5617hqu7T3GdA1hAw%40mail.gmail.com > Thanks for informing. PFA the updated patch. I have changed the numbering of enum PartitionRangeDatumKind since I have to include DEFAULT as well. If you have better ideas, let me know. -- Beena Emerson EnterpriseDB: http://www.enterprisedb

[HACKERS] Minor comment update in partition.c

The commit d363d42bb9a4399a0207bd3b371c966e22e06bd3 changed RangeDatumContent *content to PartitionRangeDatumKind *kind but a comment on function partition_rbound_cmp was left unedited and it still mentions content1 instead of kind1. PFA the patch to fix this. -- Beena Emerson EnterpriseDB

Re: [HACKERS] Adding support for Default partition in partitioning

tting > them merged here won't be an issue, mostly will be just like one more patch > on top my patches. > I have posted the updated patch which can be applied over the v22 patches submitted here. https://www.postgresql.org/message-id/CAOG9ApGEZxSQD-ZD3icj_CwTmprSGG7sZ_r3k9m4rmcc6ozr%3Dg%40ma

Re: [HACKERS] Default Partition for Range

gres(# b int NOT NULL CHECK (b >= 1 AND b <= 10) > postgres(# ); > CREATE TABLE > > postgres=# ALTER TABLE range_parted ATTACH PARTITION part1 FOR VALUES FROM > (1, 1) TO (1, 10); > ALTER TABLE > postgres=# CREATE TABLE partr_def1 PARTITION OF range_parted DEF

Re: [HACKERS] Default Partition for Range

Thank you for your review Dilip and Rahila. PFA the updated patch which is rebased to Jeevan's latest list partition patch [1] and also handles your comments. https://www.postgresql.org/message-id/CAOgcT0OARciE2X%2BU0rjSKp9VuC279dYcCGkc3nCWKhHQ1_m2rw%40mail.gmail.com -- Beena Emerson

Re: [HACKERS] Default Partition for Range

On Mon, Jul 3, 2017 at 8:00 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Fri, Jun 30, 2017 at 11:56 AM, Beena Emerson <memissemer...@gmail.com> > wrote: >> Hello Dilip, >> >> On Wed, Jun 21, 2017 at 6:27 PM, Dilip Kumar <dilipbal...@gmail.com>

Re: [HACKERS] increasing the default WAL segment size

On Thu, Jul 6, 2017 at 3:21 PM, tushar <tushar.ah...@enterprisedb.com> wrote: > On 07/06/2017 12:04 PM, Beena Emerson wrote: >> >> The 04-initdb-walsegsize_v2.patch has the following improvements: >> - Rebased over new 03 patch >> - Pass the wal-segsize intidb opti

Re: [HACKERS] increasing the default WAL segment size

Hello, On Tue, Mar 28, 2017 at 1:06 AM, Beena Emerson <memissemer...@gmail.com> wrote: > Hello, > > On Sat, Mar 25, 2017 at 10:32 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: >> >> At this point, I suggest splitting this patch

Re: [HACKERS] Default Partition for Range

toring the tri-state value. */ > boundinfo->content[i][j] = rbounds[i]->content[j]; > > Thank you for your review and analysis. I have updated the patch. - bound->content is set to RANGE_DATUM_DEFAULT for each of the keys and not just the first one. - Improve the way of handl

Re: [HACKERS] Default Partition for Range

be applied on Jeevn's partition patch (http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg316818.html) which can be applied over commit a12c09ad86e60a8acb269744b8ee86429dda2cd8. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] Default Partition for Range

On Wed, Jun 28, 2017 at 12:34 PM, Rahila Syed <rahilasye...@gmail.com> wrote: > Hi Beena, > > I started testing and reviewing the patch. Can you update the patch as v5 > patch does not apply cleanly on master? > I am currently working on Dilip's comments, I will update the pa

Re: [HACKERS] Default Partition for Range

Hello, PFA the updated patch. This is rebased over v21 patches of list partition. (http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg316818.html) -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company default_range_partition_v5.patch

Re: [HACKERS] Default Partition for Range

Hello Dilip, On Mon, Jun 5, 2017 at 8:44 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Mon, Jun 5, 2017 at 1:43 AM, Beena Emerson <memissemer...@gmail.com> wrote: >> The new patch is rebased over default_partition_v18.patch >> [http://www.mail-archive.com/p

Re: [HACKERS] Default Partition for Range

The regression comment change from 'fail' -> ' Following statement should fail' and 'ok' -> 'Following should complete successfully' is ignored since other tests in the file had similar comments The new patch is rebased over default_partition_v18.patch [http://www.mail-archive.com/pgsql-hackers

Re: [HACKERS] Adding support for Default partition in partitioning

hat are throwing violation > error > but are not local to execMain.c. > ok thanks. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Adding support for Default partition in partitioning

; Regards, > Jeevan Ladhe > What is the reason the new patch does not mention of violating rows when a new partition overlaps with default? Is it because more than one row could be violating the condition? -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreS

Re: [HACKERS] Default Partition for Range

on get_qual_for_range can be directly passed > false instead. > > - Following comment for function get_qual_for_range_default() implies that > this > function returns bool, but the actually it returns a List. > + * > + * If DEFAULT is the only partiton for the table then this returns TRUE.

Re: [HACKERS] Adding support for Default partition in partitioning

onBoundSpec and then have a general check for both list and range. Though listdatums, upperdatums and lowerdatums are set to default for a DEFAULt partition, it does not seem proper that we check listdatums for range as well. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise Po

Re: [HACKERS] Default Partition for Range

mply return that no partition > - * exists > + * A null partition key is only acceptable if null-accepting list > + * partition exists. > */ In RANGE, initially NULL was not allowed, now NULL is routed to default. I have only removed the check for null in RANGE and k

Re: [HACKERS] Adding support for Default partition in partitioning

> > [1] http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg315490.html > This needs a rebase again. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] Adding support for Default partition in partitioning

fault. It should be updated. DROP TABLE list1; CREATE TABLE list1 (a int) PARTITION BY LIST (a); CREATE TABLE list1_1 (LIKE list1); ALTER TABLE list1 ATTACH PARTITION list1_1 FOR VALUES IN (2); CREATE TABLE list1_def PARTITION OF list1 DEFAULT; INSERT INTO list1 VALUES (NULL); SELECT * FROM l

Re: [HACKERS] Default Partition for Range

Hello, On Mon, May 22, 2017 at 11:29 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Mon, May 22, 2017 at 7:27 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > Would it be more readable if this reads as NOT > (constraint_for_partition_1 || co

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, Patch for default range partition has been added. PFA the rebased v12 patch for the same. I have not removed the has_default variable yet. Default range partition: https://www.postgresql.org/message-id/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg%40mail.gmail.com -- Beena Emerson

[HACKERS] Default Partition for Range

d/flat/CAOgcT0PLPge%3D5U6%3DGU5SnC3_8yutCbWWOiUva3Cw94M9zpbvgQ%40mail.gmail.com>* -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company default_range_partition_WIP.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] Adding support for Default partition in partitioning

is. > > >There's an existing function that you can use to concatenate two lists > >instead of open-coding it. > Will check this. > > >you should really add the documentation and > >regression tests which you mentioned as a TODO. And run the code > >through pgi

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, May 11, 2017 at 7:37 PM, Rahila Syed wrote: > Hello, > > Please find attached an updated patch with review comments and bugs > reported till date implemented. > Hello Rahila, Tested on "efa2c18 Doc fix: scale(numeric) returns integer, not numeric." (1) With the

Re: [HACKERS] multi-column range partition constraint

On Tue, May 2, 2017 at 2:47 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Beena, > > On 2017/05/02 17:47, Beena Emerson wrote: > > Hello Amit, > > > > On Tue, May 2, 2017 at 12:21 PM, Amit Langote < > langote_amit...@lab.ntt.co.jp > >

Re: [HACKERS] multi-column range partition constraint

y promptly until Monday 05/08. > > I got the following warning on compiling: partition.c: In function ‘make_partition_op_expr’: partition.c:1267:2: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized] return result; -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Crash when partition column specified twice

wice > > and instead tried to delete the same ColumnDef from a list twice, causing > > the crash. > > > > Attached fixes that. > > Patch rebased, because of a conflict with b9a3ef55b2. > > Thanks, > Amit > > > -- > Sent via pgsql-hackers mailing

Re: [HACKERS] increasing the default WAL segment size

614 I did not get any degradation, in fact, higher values showed performance improvement for higher client count. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] increasing the default WAL segment size

od), and allowing all 2^n values up to that > limit. I think the majority consensus is to use all valid values. Since 1GB is what we have finalized as the upper limit, lets continue with that for now. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] increasing the default WAL segment size

d. We can see that smaller chunks take lesser time for the same amount of WAL (128 and 256, 512 and 1024). But these tests are not large enough to conclude. Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company initdb_update_regress.patch Description: Bina

Re: [HACKERS] increasing the default WAL segment size

; limit should be 128 MB. ;-) > I ran a couple of tests for 16MB and 1GB and found less than 4% performance dip. I am currently running test to check consistency of the results and for various sizes. I will update soon. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] increasing the default WAL segment size

Hello, On Wed, Apr 5, 2017 at 4:59 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 5 April 2017 at 06:04, Beena Emerson <memissemer...@gmail.com> wrote: > > I see various issues raised but not properly addressed > > 1. we would need to drop support for segment siz

Re: [HACKERS] increasing the default WAL segment size

around 256 MB, things got > really slow. > Would it be better if just increase the limit to 128MB for now? In next we can change the WAL file name format and expand the range? -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] increasing the default WAL segment size

Hello, On Fri, Mar 31, 2017 at 11:20 AM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > On Fri, Mar 31, 2017 at 10:40 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > > On 30 Mar 2017 15:10, "Kuntal Ghosh" <kuntalghosh.2...@gmail.com> wrote: >

Re: [HACKERS] increasing the default WAL segment size

Hello, Thanks for testing my patch. On 30 Mar 2017 15:10, "Kuntal Ghosh" <kuntalghosh.2...@gmail.com> wrote: On Tue, Mar 28, 2017 at 1:06 AM, Beena Emerson <memissemer...@gmail.com> wrote: > On Sat, Mar 25, 2017 at 10:32 PM, Peter Eisentraut > <peter.ei

Re: [HACKERS] increasing the default WAL segment size

eck the config values. What other tests do you have in mind? Checking the various tools? -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company 01-add-XLogSegmentOffset-macro.patch Description: Binary data 02-increase-max-wal-segsize.patch Descripti

Re: [HACKERS] increasing the default WAL segment size

Hello, On Wed, Mar 22, 2017 at 9:41 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > On Wed, Mar 22, 2017 at 3:14 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > PFA an updated patch which fixes a minor bug I found. It only increases > the > &g

Re: [HACKERS] increasing the default WAL segment size

atch which fixes a minor bug I found. It only increases the string size in pretty_wal_size function. The 01-add-XLogSegmentOffset-macro.patch has also been rebased. -- Thank you, Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company 02-initdb-walsegsize-v7.

Re: [HACKERS] increasing the default WAL segment size

. Consequently, the size of the variables increase automatically according to the wal_segment_size. This behaviour is similar to that of existing code. I have also run pg_indent on the files. On Mon, Mar 20, 2017 at 11:37 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Hello, > >

Re: [HACKERS] increasing the default WAL segment size

Hello, PFA the updated patch. On Fri, Mar 17, 2017 at 6:40 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Mar 14, 2017 at 1:44 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > > Attached is the updated patch. It fixes the issues and also updates few &g

Re: [HACKERS] increasing the default WAL segment size

dd a check to see if it only contains numbers? or would it be better to allow the use of the units and make appropriate code changes? -- Thank you, Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] increasing the default WAL segment size

modify it . > Removed. > > 2)Getting "Aborted (core dumped)" error at the time of running > pg_basebackup , > *(this issue is only coming on Linux32 ,not on Linux64) * we have double > check to confirm it . > Can you please check with the new patch? -- Tha

Re: [HACKERS] increasing the default WAL segment size

; [centos@tushar-centos bin]$ >>> >> >> Just to confirm, was this done with configure flag --with-wal-segsize=4 ? >> > > we also have configure with the option "*--with-wal-segsize=4*" and > getting warning. > ./configure --with-zlib --enable-debug --enable-cassert > --enable-depend --prefix=$PWD/inst --with-openssl CFLAGS="-g -O0" > *--with-wal-segsize=4* > > configure: WARNING: unrecognized options: --with-wal-segsize > configure option was for the HEAD, without the patch applied. I guess, I am missing something regarding the 32 bit machines, I am looking into it. Thank you, -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] increasing the default WAL segment size

Hello, Thank you testing. I just wanted to confirm few things since I do not have linux32 setup yet. On Fri, Mar 10, 2017 at 1:09 PM, tushar <tushar.ah...@enterprisedb.com> wrote: > On 03/10/2017 11:23 AM, Beena Emerson wrote: > > >> Thank you for your reviews Kuntal, Jim,

Re: [HACKERS] increasing the default WAL segment size

3. Change PATH_MAX in pg_waldump with MAXPGPATH Regarding the usage of the wal file size as the XLogSegSize, I agree with what Robert has said. Generally, the wal size will be of the expected wal_segment_size and to have it any other size, esspecially of a valid power2 value is extremely rare an

Re: [HACKERS] increasing the default WAL segment size

olFile written. Unlike pg_resetwal and pg_rewind, pg_basebackup cannot access the Control file. It only accesses the wal log folder. So we get the XLogSegSize from the SHOW command using replication connection. As Kuntal pointed out, I might need to set it from pg_receivewal.c as well. Thank

Re: [HACKERS] increasing the default WAL segment size

Remove useless duplicate inclusions of system header files. -- Thank you, Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company 02-initdb-walsegsize-v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) T

Re: [HACKERS] increasing the default WAL segment size

On Mon, Feb 20, 2017 at 2:47 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Hello, > > On Thu, Feb 16, 2017 at 3:37 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> > wrote: > >> On Mon, Feb 6, 2017 at 11:09 PM, Beena Emerson <memissemer...@gmail.com&

Re: [HACKERS] increasing the default WAL segment size

Hello, On Thu, Feb 16, 2017 at 3:37 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > On Mon, Feb 6, 2017 at 11:09 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > > > Hello, > > PFA the updated patches. > I've started reviewing the patches.

Re: [HACKERS] Proposal : For Auto-Prewarm.

through > > launch_pg_prewarm_dump(), I can go back to original design where there > > will be one worker which loads and then dumps periodically. And > > launch_pg_prewarm_dump will relaunch dump only activity of that > > worker. Does this sound good? > > > > Won't it be simple if you consider -1 as a value to just load library? > For *_interval = -1, it will neither load nor dump. > > +1 That is what I thought was the behaviour we decided upon for -1. -- Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] Proposal : For Auto-Prewarm.

Hello, On Tue, Feb 7, 2017 at 5:14 PM, Mithun Cy <mithun...@enterprisedb.com> wrote: > On Tue, Feb 7, 2017 at 12:24 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > > On Tue, Feb 7, 2017 at 11:53 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > >&

Re: [HACKERS] Proposal : For Auto-Prewarm.

Hello, On Tue, Feb 7, 2017 at 5:52 PM, Mithun Cy <mithun...@enterprisedb.com> wrote: > Thanks Beena, > > On Tue, Feb 7, 2017 at 4:46 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > Few more comments: > > > > = Background worker messages: >

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Tue, Feb 7, 2017 at 3:01 PM, Mithun Cy <mithun...@enterprisedb.com> wrote: > On Tue, Feb 7, 2017 at 11:53 AM, Beena Emerson <memissemer...@gmail.com> > wrote: > > launched by other applications. Also with max_worker_processes = 2 and > > restart, the syst

Re: [HACKERS] Proposal : For Auto-Prewarm.

s terminated by signal 11: Segmentation fault I think the document should also mention that an appropriate max_worker_processes should be set else the dump worker will not be launched at all. -- Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] increasing the default WAL segment size

Hello, PFA the updated patches. On Fri, Jan 27, 2017 at 2:17 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Hello Andres, > > Thank you for your review. > > On Fri, Jan 27, 2017 at 12:39 AM, Andres Freund <and...@anarazel.de> > wrote: > >> Hi, &g

Re: [HACKERS] increasing the default WAL segment size

Hello Andres, Thank you for your review. On Fri, Jan 27, 2017 at 12:39 AM, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2017-01-23 11:35:11 +0530, Beena Emerson wrote: > > Please find attached an updated WIP patch. I have incorporated almost all > > comm

Re: [HACKERS] Proposal : For Auto-Prewarm.

t would store in the cluster directory else in the location provided. We can update this parameter in standby for it to access the file. Thoughts? -- Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] \h tab-completion

On Wed, Jan 25, 2017 at 11:43 AM, Michael Paquier <michael.paqu...@gmail.com > wrote: > On Wed, Jan 25, 2017 at 3:03 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > I think the following change in tab-complete.c would do the trick. > > > &

Re: [HACKERS] \h tab-completion

MAPPING FOR DATABASE FOREIGN DATA WRAPPER LANGUAGE PUBLICATION SERVERTEXT SEARCH VIEW DEFAULT PRIVILEGESFOREIGN TABLE LARGE OBJECT ROLE SUBSCRIPTION TRIGGER -- Thank you, Beena Emerson Have a Great Day! t

Re: [HACKERS] Proposal : For Auto-Prewarm.

y > being loaded. If I get a chance I'll try it again. Hope u added the following to the conf file: shared_preload_libraries = 'pg_autoprewarm' # (change requires restart) pg_autoprewarm.buff_dump_interval=20 Even after this u could not see the message then that's strange. -- Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] Proposal : For Auto-Prewarm.

cks loaded from dump” or something similar. 4. Also, the message while dumping says: 2017-01-24 16:15:17.712 IST [90061] LOG: Buffer Dump: saved metadata of 272 blocks It would be better to write the module name in message instead of "Buffer Dump" Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] increasing the default WAL segment size

+#define XLOG_SEG_SIZE XLogSegSize would it be better to just use one variable XLogSegSize everywhere. But few external modules could be using XLOG_SEG_SIZE. Thoughts? 9. Documentation will be added in next version of patch. -- Beena Emerson On Sat, Jan 21, 2017 at 5:30 AM, Michael Paquier <

Re: [HACKERS] increasing the default WAL segment size

On Tue, Jan 17, 2017 at 12:50 PM, Beena Emerson <memissemer...@gmail.com> wrote: > > > On Tue, Jan 17, 2017 at 12:38 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Tue, Jan 17, 2017 at 4:06 PM, Beena Emerson <memissemer...@gmail.com> &

Re: [HACKERS] increasing the default WAL segment size

On Tue, Jan 17, 2017 at 12:38 PM, Michael Paquier <michael.paqu...@gmail.com > wrote: > On Tue, Jan 17, 2017 at 4:06 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > I have already made patch for the generic SHOW replication command > > (attached) and am w

Re: [HACKERS] increasing the default WAL segment size

This would make sense as a new option of pg_test_fsync. > > A performance study would be a good idea as well. Regarding the > generic SHOW command in the replication protocol, I may do it for next > CF, I have use cases for it in my pocket. > > Thank you for your review. I have alread

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

Hello, On Wed, Jan 11, 2017 t 6:06 PM, Beena Emerson <memissemer...@gmail.com> wrote: > > > On Fri, Jan 6, 2017 at 11:54 AM, Ryan Murphy <ryanfmur...@gmail.com> > wrote: > >> The following review has been posted through the commitfest application: >> m

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

after a while): > > === > 1 of 55 tests failed. > === > > > I am sure you would get this error even without the patch. -- Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] increasing the default WAL segment size

On Fri, Jan 6, 2017 at 11:36 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Jan 5, 2017 at 8:39 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > On Tue, Jan 3, 2017 at 5:46 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wr

Re: [HACKERS] increasing the default WAL segment size

nt of the SQL > command and be able to query parameter values? > This patch only needed the wal_segment_size and hence I made this specific command. How often and why would we need other parameter values in the replication connection? Making it a more general command to fetch any parameter can be a separate topic. If it gets consensus, maybe it could be done and used here. Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] increasing the default WAL segment size

_SEG_SIZE (16*1024*1024) > > That comment isn't really accurate. It would be more useful to explain > that DEFAULT_XLOG_SEG_SIZE is the default size of a WAL segment used by > initdb if a different value isn't specified. > I will correct this comment The new version of the patch will be posted soon. Thank you, Beena Emerson Have a Great Day!

Re: [HACKERS] increasing the default WAL segment size

Hello Andres, On Tue, Dec 20, 2016 at 1:58 PM, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2016-12-19 15:14:50 +0530, Beena Emerson wrote: > > The attached patch removes --with-wal-segsize configure option and adds a > > new initdb option --wal-segsiz

Re: [HACKERS] increasing the default WAL segment size

Hello all, On Mon, Dec 19, 2016 at 3:14 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Hello all, > > Please find attached a patch to make wal segment size initdb configurable. > > The attached patch removes --with-wal-segsize configure option and adds a > new ini

Re: [HACKERS] increasing the default WAL segment size

are welcome. -- Beena Emerson Have a Great Day! initdb-walsegsize_v1.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] Specifying the log file name of pgbench -l option

Hello, On Mon, Nov 7, 2016 at 8:42 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Mon, Nov 7, 2016 at 10:52 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > Hello Sawada-san, > > > > On Mon, Nov 7, 2016 at 4:47 PM, Masahiko Sawa

Re: [HACKERS] Specifying the log file name of pgbench -l option

Hello Sawada-san, On Mon, Nov 7, 2016 at 4:47 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Wed, Nov 2, 2016 at 3:57 PM, Beena Emerson <memissemer...@gmail.com> > wrote: > > Hello, > > > > On Wed, Nov 2, 2016 at 4:16 AM, Fabien COELHO <coe...@cri.

Re: [HACKERS] Specifying the log file name of pgbench -l option

ampling-rate is better: $ pgbench --log-prefix=chk -t 20 log file prefix (--log-prefix) is allowed only when actually logging transactions pgbench --sampling-rate=1 -t 20 log sampling (--sampling-rate) is allowed only when logging transactions (-l) Thanks, Beena Emerson Have a Great Day!

Re: [HACKERS] Support for N synchronous standby servers - take 2

ethod = 'priority' Though s_r_m = 'quorum' worked fine, changing it to 'priority' caused segmentation fault. Regards, Beena Emerson Have a Great Day!

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Oct 14, 2015 at 10:38 AM, Michael Paquier wrote: > On Wed, Oct 14, 2015 at 3:02 AM, Masahiko Sawada wrote: > > > It would be good even if there are some restriction such as the > > nesting level, the group setting. > > The another new approach that I came up

Re: [HACKERS] Support for N synchronous standby servers - take 2

le into a variable which was used for further parsing which could have been avoided with multi-line GUC. - Beena Emerson -- View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5869285.html Sent from the PostgreSQL

Re: [HACKERS] Support for N synchronous standby servers - take 2

ut since no many levels or nesting is expected I am not sure how useful this will be. - Though JSON parser is inbuilt, additional code is required to check for the required format of JSON. For mini-language, new parser will have to be written. Despite all, I feel the mini-language is bette

Re: [HACKERS] Support for N synchronous standby servers - take 2

Sawada Masahiko wrote: > > I agree with adding support for multi-line GUC parameters. > But I though it is: > param = 'param1, > param2, > param3' > > This reads as 'value1,value2,value3'. Use of '\' ensures that omission the closing quote does not break the entire file.

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, Thank you Thomas and Sameer for checking the patch and giving your comments! I will post an updated patch soon. Regards, Beena Emerson

Re: [HACKERS] Support for N synchronous standby servers - take 2

. I am yet to thoroughly test the patch. Thoughts? -- Beena Emerson WIP_multiple_syncrep.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] Support for N synchronous standby servers - take 2

would also have to add additional code to check that that given JSON has the required keys and entries. For ex: The group mentioned in the s_s_names should be definied in the groups section, etc. - Beena Emerson -- View this message in context: http://postgresql.nabble.com/Support-for-N

  1   2   >