[HACKERS] relpersistence and temp table

. Was this intentional or is it a bug? Regards -Amit Khandekar -- 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] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On 12 February 2011 14:48, Alex Hunsaker bada...@gmail.com wrote: On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan and...@dunslane.net wrote: Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On 3 October 2011 22:37, Alex Hunsaker bada...@gmail.com wrote: On Mon, Oct 3, 2011 at 04:20, Amit Khandekar amit.khande...@enterprisedb.com wrote: Is there a plan to commit this issue? I am still seeing this issue on PG 9.1 STABLE branch. Attached is a small patch that targets only

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On 4 October 2011 14:04, Alex Hunsaker bada...@gmail.com wrote: On Mon, Oct 3, 2011 at 23:35, Amit Khandekar amit.khande...@enterprisedb.com wrote: WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to utf8_str, so pg_verify_mbstr_len() will not get called. That's the reason

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On 4 October 2011 22:57, Alex Hunsaker bada...@gmail.com wrote: On Tue, Oct 4, 2011 at 03:09, Amit Khandekar amit.khande...@enterprisedb.com wrote: On 4 October 2011 14:04, Alex Hunsaker bada...@gmail.com wrote: On Mon, Oct 3, 2011 at 23:35, Amit Khandekar amit.khande...@enterprisedb.com

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On 5 October 2011 12:29, Alex Hunsaker bada...@gmail.com wrote: On Wed, Oct 5, 2011 at 00:30, Alex Hunsaker bada...@gmail.com wrote: On Tue, Oct 4, 2011 at 23:46, Amit Khandekar amit.khande...@enterprisedb.com wrote: You mean the final changes in plperl_helpers.h would look like something

[HACKERS] pl/perl example in the doc no longer works in 9.1

Hi, An example in the PG documentation gives an error: http://www.postgresql.org/docs/9.1/interactive/plperl-global.html CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$ $_SHARED{myquote} = sub { my $arg = shift; $arg =~ s/(['\\])/\\$1/g; return '$arg'; };

Re: [HACKERS] information schema parameter_default implementation

I have assigned myself as reviewer for this one. The logic of pg_get_function_arg_default() looks good. I will reply with any code-level comments later, but just a quick question before that: What's the reason behind calling pg_has_role(proowner, 'USAGE') before calling

[HACKERS] information schema parameter_default implementation

On 15 September 2013 01:35, Peter Eisentraut pete...@gmx.net wrote: Here is an updated patch which fixes the bug you have pointed out. On Thu, 2013-01-31 at 18:59 +0500, Ali Dar wrote: I checked our your patch. There seems to be an issue when we have OUT parameters after the DEFAULT

Re: [HACKERS] Assertions in PL/PgSQL

On 16 September 2013 03:43, Marko Tiikkaja ma...@joh.to wrote: On 2013-09-15 23:23, Jaime Casanova wrote: If using ASSERT as keyword is not acceptable, not that i agree but in case. What about using RAISE EXCEPTION WHEN (condition) I was going to suggest the same idea: Extend RAISE syntax

Re: [HACKERS] Assertions in PL/PgSQL

On 23 September 2013 10:10, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/9/22 Jaime Casanova ja...@2ndquadrant.com El 21/09/2013 17:16, Jaime Casanova ja...@2ndquadrant.com escribió: On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja ma...@joh.to wrote: On 9/20/13 12:09 PM, Amit

Re: [HACKERS] Assertions in PL/PgSQL

On 23 September 2013 14:33, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/9/23 Amit Khandekar amit.khande...@enterprisedb.com On 23 September 2013 10:10, Pavel Stehule pavel.steh...@gmail.comwrote: 2013/9/22 Jaime Casanova ja...@2ndquadrant.com El 21/09/2013 17:16, Jaime

Re: [HACKERS] pg_dump/restore encoding woes

On 27 August 2013 20:06, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 26.08.2013 18:59, Tom Lane wrote: Heikki Linnakangashlinnakangas@**vmware.com hlinnakan...@vmware.com writes: The pg_dump -E option just sets client_encoding, but I think it would be better for -E to only set

[HACKERS] information schema parameter_default implementation

On 15 September 2013 01:35, Peter Eisentraut pete...@gmx.net wrote: Here is an updated patch which fixes the bug you have pointed out. On Thu, 2013-01-31 at 18:59 +0500, Ali Dar wrote: I checked our your patch. There seems to be an issue when we have OUT parameters after the DEFAULT

Re: [HACKERS] pg_dump/restore encoding woes

On 25 September 2013 12:49, Amit Khandekar amit.khande...@enterprisedb.comwrote: 0003-Convert-object-names-to-**archive-encoding-before-matc.**patch Use iconv(3) in pg_restore to do encoding conversion in the client. This involves a lot of autoconf changes that I'm not 100% sure about, other

[HACKERS] information schema parameter_default implementation

On 15 September 2013 01:35, Peter Eisentraut pete...@gmx.net wrote: Here is an updated patch which fixes the bug you have pointed out. On Thu, 2013-01-31 at 18:59 +0500, Ali Dar wrote: I checked our your patch. There seems to be an issue when we have OUT parameters after the DEFAULT

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 18 October 2013 17:07, Rajeev rastogi rajeev.rast...@huawei.com wrote: From the following mail, copy behaviour between stdin and normal file having some inconsistency. http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com The issue was that if copy execute from

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 18 November 2013 18:00, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 18 November 2013, Amit Khandekar wrote: On 18 October 2013 17:07, Rajeev rastogi rajeev.rast...@huawei.com wrote: From the following mail, copy behaviour between stdin and normal file having some inconsistency

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 19 November 2013 16:05, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 19 November 2013, Amit Khandekar wrote: On 18 November 2013 18:00, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 18 November 2013, Amit Khandekar wrote: Please find the patch for the same and let me know

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 20 November 2013 17:40, Rajeev rastogi rajeev.rast...@huawei.com wrote: You mean to say that I should change the patch to keep only COPY FROM related changes and remove changes related to COPY TO. If yes, then I shall change the patch accordingly and also mention same in documentation

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 20 November 2013 18:11, Robert Haas robertmh...@gmail.com wrote: On Wed, Nov 20, 2013 at 4:56 AM, Amit Khandekar amit.khande...@enterprisedb.com wrote: So I think it is best to solve this as a different issue, and we should , for this commitfest, fix only COPY FROM. Once the \COPY

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 21 November 2013 10:13, Tom Lane t...@sss.pgh.pa.us wrote: Amit Khandekar amit.khande...@enterprisedb.com writes: Rather than a behaviour change, it is a bug that we are fixing. User already expects to see copy status printed, so as per user there would be no behaviour change

Re: [HACKERS] Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

On 1 November 2013 16:32, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote: From: Fujii Masao [mailto:masao.fu...@gmail.com] This is what I'm looking for! This feature is really useful for tuning work_mem when using full text search with pg_trgm. I'm not sure if it's good idea to show

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 22 November 2013 16:14, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 21 November 2013, Amit Khandekar amit.khande...@enterprisedb.com wrote: Ok. we will then first fix the \COPY TO issue where it does not revert back the overriden psql output file handle. Once this is solved, fix

Re: [HACKERS] Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

On 25 November 2013 13:37, Etsuro Fujita fujita.ets...@lab.ntt.co.jpwrote: Reconsidering that, I wish to know your opinion. The patch shows the number of exact/lossy pages that has been fetched in a bitmap heap scan. But the number varies with the fraction of tuples to be retrieved like the

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 25 November 2013 15:25, Rajeev rastogi rajeev.rast...@huawei.com wrote: OK. I have revised the patch as per the discussion. Could you please submit only the \COPY fix first ? The attached patch also contains the fix for the original COPY status fix. Now if \copy command is called then, we

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 27 November 2013 09:59, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 26 November 2013, Amit Khandelkar wrote: On 26 November 2013 18:59, Amit Khandekar amit.khande...@enterprisedb.com wrote: On 25 November 2013 15:25, Rajeev rastogi rajeev.rast...@huawei.com wrote: OK. I

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 29 November 2013 19:20, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 26 November 2013, Amit Khandelkar wrote: Can you please submit the \COPY patch as a separate patch ? Since these are two different issues, I would like to have these two fixed and committed separately. You can

Re: [HACKERS] Proposal: variant of regclass

Hi, I have begun the review as part of the commitfest. Below are my comments *_guts() functions are defined as returning Datum, while they are actually returning Oid. They should be defined as returning Oid. Also the PG_RETURN_OID() has been still used in some of the *_guts()

Re: [HACKERS] Proposal: variant of regclass

On 22 January 2014 13:09, Tatsuo Ishii is...@postgresql.org wrote: I, as a user would be happier if we also have to_regprocedure() and to_regoperator(). The following query looks a valid use-case where one needs to find if a particular function exists. Using to_regproc('sum') does not

Re: Fwd: [HACKERS] Proposal: variant of regclass

There are duplicate oids in pg_proc.h : make[3]: Entering directory `/tmp/git-pg/src/backend/catalog' cd ../../../src/include/catalog '/usr/bin/X11/perl' ./duplicate_oids 3180 3195 3196 3197 - There is a whitespace diff in regoperatorin and regprocedurein() definition.

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

On 13 June 2014 14:10, Abhijit Menon-Sen a...@2ndquadrant.com wrote: nbtxlog.c:btree_xlog_vacuum() contains the following comment: * XXX we don't actually need to read the block, we just need to * confirm it is unpinned. If we had a special call into the * buffer manager we

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

On 3 July 2014 16:59, Simon Riggs si...@2ndquadrant.com wrote: I think we should say this though LockBufHdr(buf); valid = ((buf-flags BM_VALID) != 0); if (valid) PinBuffer_Locked(buf); else UnlockBufHdr(buf); since otherwise we would access the buffer flags without the

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

On 4 July 2014 19:11, Abhijit Menon-Sen a...@2ndquadrant.com wrote: Updated patch attached, thanks. Amit: what's your conclusion from the review? Other than some minor comments as mentioned below, I don't have any more issues, it looks all good. XLogLockBlockRangeForCleanup() function

Re: [HACKERS] delta relations in AFTER triggers

On 21 June 2014 23:36, Kevin Grittner kgri...@ymail.com wrote: Kevin Grittner kgri...@ymail.com wrote: I didn't change the tuplestores to TID because it seemed to me that it would preclude using transition relations with FDW triggers, and it seemed bad not to support that. Does anyone see a

Re: [HACKERS] delta relations in AFTER triggers

On 7 August 2014 19:49, Kevin Grittner kgri...@ymail.com wrote: Amit Khandekar amit.khande...@enterprisedb.com wrote: On 21 June 2014 23:36, Kevin Grittner kgri...@ymail.com wrote: Kevin Grittner kgri...@ymail.com wrote: I didn't change the tuplestores to TID because it seemed to me

Re: [HACKERS] delta relations in AFTER triggers

On 12 August 2014 20:09, Kevin Grittner kgri...@ymail.com wrote: Amit Khandekar amit.khande...@enterprisedb.com wrote: On 7 August 2014 19:49, Kevin Grittner kgri...@ymail.com wrote: Amit Khandekar amit.khande...@enterprisedb.com wrote: I tried to google some SQLs that use REFERENCING clause

Re: [HACKERS] delta relations in AFTER triggers

The execution level itself was almost trivial; it's getting the tuplestore reference through the parse analysis and planning phases that is painful for me. I am not sure why you think we would need to refer the tuplestore in the parse analysis and planner phases. It seems that we would need

Re: [HACKERS] delta relations in AFTER triggers

On 15 August 2014 04:04, Kevin Grittner kgri...@ymail.com wrote: Amit Khandekar amit.khande...@enterprisedb.com wrote: The execution level itself was almost trivial; it's getting the tuplestore reference through the parse analysis and planning phases that is painful for me. I am not sure why

[HACKERS] Resetting crash time of background worker

BGW_NEVER_RESTART. -Amit Khandekar

Re: [HACKERS] Resetting crash time of background worker

On 17 March 2015 at 19:12, Robert Haas robertmh...@gmail.com wrote: On Tue, Mar 17, 2015 at 1:33 AM, Amit Khandekar amitdkhan...@gmail.com wrote: I think we either have to retain the knowledge that the worker has crashed using some new field, or else, we should reset the crash time only

Re: [HACKERS] asynchronous and vectorized execution

On 21 July 2016 at 15:20, Kyotaro HORIGUCHI wrote: > > After some consideration, I found that ExecAsyncWaitForNode > cannot be reentrant because it means that the control goes into > async-unaware nodes while having not-ready nodes, that is > inconsistent state.

Re: [HACKERS] asynchronous and vectorized execution

We may also want to consider handling abstract events such as "tuples-are-available-at-plan-node-X". One benefit is : we can combine this with batch processing. For e.g. in case of an Append node containing foreign scans, its parent node may not want to process the Append node result until Append

Re: [HACKERS] Parallel Append implementation

Ashutosh Bapat wrote: >> We may want to think about a third goal: preventing too many workers >> from executing the same plan. As per comment in get_parallel_divisor() >> we do not see any benefit if more than 4 workers execute the same >> node. So, an append node

Re: [HACKERS] Parallel Append implementation

v2 patch was not rebased over the latest master branch commits. Please refer to the attached ParallelAppend_v3.patch, instead. On 6 February 2017 at 11:06, Amit Khandekar <amitdkhan...@gmail.com> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >>> We

Re: [HACKERS] Parallel Append implementation

On 15 February 2017 at 18:40, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Feb 15, 2017 at 4:43 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >>> On 14 February 2017 at 22:35, Robert Haas <robertmh...@gmail.com> wrote: >>>> For exampl

Re: [HACKERS] UPDATE of partition key

be possible to find the root partition with the help of pg_partitioned_table, and then run ExecFindPartition() again using the root. Will check. I am not sure right now how involved that would turn out to be, but I think that logic would not change the existing code, so in that sense it is not inva

Re: [HACKERS] UPDATE of partition key

On 16 February 2017 at 20:53, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Feb 16, 2017 at 5:47 AM, Greg Stark <st...@mit.edu> wrote: >> On 13 February 2017 at 12:01, Amit Khandekar <amitdkhan...@gmail.com> wrote: >>> There are a few things that can

Re: [HACKERS] Parallel Append implementation

Ashutosh Bapat wrote: > Do we have any performance measurements where we see that Goal B > performs better than Goal A, in such a situation? Do we have any > performance measurement comparing these two approaches in other > situations. If implementation for Goal B

Re: [HACKERS] Parallel Append implementation

On 16 February 2017 at 20:37, Robert Haas wrote: > I'm not sure that it's going to be useful to make this logic very > complicated. I think the most important thing is to give 1 worker to > each plan before we give a second worker to any plan. In general I > think it's

Re: [HACKERS] UPDATE of partition key

On 14 February 2017 at 22:24, David Fetter <da...@fetter.org> wrote: > On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote: >> Currently, an update of a partition key of a partition is not >> allowed, since it requires to move the row(s) into the applicable >>

Re: [HACKERS] Parallel Append implementation

On 14 February 2017 at 22:35, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Feb 6, 2017 at 12:36 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >>> Now that I think of that, I think for implementing above, we need to >>> keep track of per-su

Re: [HACKERS] Parallel Append implementation

> On 14 February 2017 at 22:35, Robert Haas wrote: >> For example, suppose that I have a scan of two children, one >> of which has parallel_workers of 4, and the other of which has >> parallel_workers of 3. If I pick parallel_workers of 7 for the >> Parallel Append, that's

[HACKERS] UPDATE of partition key

itioned and inheritence tables, the time taken linearly rose with the number of rows. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company update_trigger.sql Description: Binary data update-partition-key.patch Description: Binary data -- Sent via pgsql-hackers ma

Re: [HACKERS] UPDATE of partition key

On 16 February 2017 at 14:42, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/02/16 17:55, Amit Khandekar wrote: >> On 16 February 2017 at 12:57, Amit Langote wrote: >>> On 2017/02/16 15:50, Amit Khandekar wrote: >>>> On 15 February 2017 at 2

Re: [HACKERS] UPDATE of partition key

On 16 February 2017 at 12:57, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/02/16 15:50, Amit Khandekar wrote: >> On 15 February 2017 at 20:26, David Fetter <da...@fetter.org> wrote: >>> When an UPDATE can't happen, there are often ways to hint

Re: [HACKERS] Parallel Append implementation

On 16 February 2017 at 20:37, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Feb 16, 2017 at 1:34 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >>> What I was thinking about is something like this: >>> >>> 1. First, take the

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

r(); proc_exit(0); /* done */ } -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company On 16 January 2017 at 15:54, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Mon, Jan 16, 2017 at 1:50 PM, Amit Khandekar <amitdkhan...@gmail.com>

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On 18 January 2017 at 02:32, Robert Haas wrote: > On Fri, Jan 13, 2017 at 8:45 AM, Alvaro Herrera > wrote: >> I think this is the same problem as reported in >>

Re: [HACKERS] UPDATE of partition key

ing execution phase only once for the very first time we find the update requires row movement, then we can re-use the info. One more thing I noticed is that, in case of update-returning, the ExecDelete() will also generate result of RETURNING, which we are discarding. So this is a waste. We should not ev

Re: [HACKERS] asynchronous execution

On 4 October 2016 at 02:30, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Sep 28, 2016 at 12:30 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 24 September 2016 at 06:39, Robert Haas <robertmh...@gmail.com> wrote: >>> Since Kyotaro Hori

Re: [HACKERS] asynchronous and vectorized execution

On 13 September 2016 at 20:20, Robert Haas wrote: > On Mon, Aug 29, 2016 at 4:08 AM, Kyotaro HORIGUCHI > wrote: > > [ new patches ] > > +/* > + * We assume that few nodes are async-aware and async-unaware > +

Re: [HACKERS] asynchronous execution

e could resolve the plan state recursion issue by explicitly making sure the same plan state does not get called again while it is already executing. Thanks -Amit Khandekar -- 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] Parallel bitmap heap scan

On 19 October 2016 at 09:47, Dilip Kumar wrote: > On Tue, Oct 18, 2016 at 1:45 AM, Andres Freund wrote: >> I don't quite understand why the bitmap has to be parallel at all. As >> far as I understand your approach as described here, the only thing that

Re: [HACKERS] Parallel bitmap heap scan

l.com> wrote: >> On Fri, Nov 18, 2016 at 9:59 AM, Amit Khandekar <amitdkhan...@gmail.com> >> wrote: >> >> Thanks for the review.. > > I have worked on these comments.. >> >>> In pbms_is_leader() , I didn't clearly understand th

[HACKERS] Parallel Append implementation

Planning time: 0.493 ms Execution time: 29662.791 ms (24 rows) Thanks to Robert Haas and Rushabh Lathia for their valuable inputs while working on this feature. [1] Old mail thread : https://www.postgresql.org/message-id/flat/9A28C8860F777E439AA12E8AEA7694F80115DEB8%40BPXM15GP.gisp.nec.co.jp#9a2

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

e won't be chosen again, so there's no harm just calling this function. > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres D

Re: [HACKERS] Parallel Append implementation

Thanks Ashutosh for the feedback. On 6 January 2017 at 17:04, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Fri, Dec 23, 2016 at 10:51 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Currently an Append plan node does not execute its

Re: [HACKERS] Parallel Append implementation

On 23 March 2017 at 05:55, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Mar 22, 2017 at 4:49 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Attached is the updated patch that handles the changes for all the >> comments except the cost changes pa

Re: [HACKERS] Parallel Append implementation

On 24 March 2017 at 13:11, Rajkumar Raghuwanshi wrote: > I have given patch on latest pg sources (on commit > 457a4448732881b5008f7a3bcca76fc299075ac3). configure and make all > install ran successfully, but initdb failed with below error. >

Re: [HACKERS] UPDATE of partition key

On 27 March 2017 at 13:05, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> Also, there are a few places in the documentation mentioning that such >> updates cause error, >> which will need to be updated. Perhaps also add some explanatory notes >> about the mech

Re: [HACKERS] UPDATE of partition key

redundantly, which I am yet to handle this. On 23 March 2017 at 07:04, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Amit, > > Thanks for the updated patch. > > On 2017/03/23 3:09, Amit Khandekar wrote: >> Attached is v2 patch which implements the above optimization. >

Re: [HACKERS] UPDATE of partition key

On 25 March 2017 at 01:34, Amit Khandekar <amitdkhan...@gmail.com> wrote: I am yet to handle all of your comments, but meanwhile , attached is > an updated patch, that handles RETURNING. > > Earlier it was not working because ExecInsert() did not return any > RETURNING claus

Re: [HACKERS] UPDATE of partition key

On 17 March 2017 at 16:07, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 6 March 2017 at 15:11, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> >>>> But that starts to sound less attractive when one realizes that >>>> that will occur fo

Re: [HACKERS] Parallel Append implementation

On 24 March 2017 at 00:38, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 23 March 2017 at 16:26, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> On 23 March 2017 at 05:55, Robert Haas <robertmh...@gmail.com> wrote: >>> >>> So in your example w

Re: [HACKERS] Parallel Append implementation

On 23 March 2017 at 16:26, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 23 March 2017 at 05:55, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Mar 22, 2017 at 4:49 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >>> Attached is the updated pa

Re: [HACKERS] Parallel Append implementation

On 16 March 2017 at 18:18, Ashutosh Bapat wrote: > + * Check if we are already finished plans from parallel append. This > + * can happen if all the subplans are finished when this worker > + * has not even started returning tuples. > +

Re: [HACKERS] Parallel Append implementation

On 17 March 2017 at 01:37, Robert Haas wrote: > - You've added a GUC (which is good) but not documented it (which is > bad) or added it to postgresql.conf.sample (also bad). > > - You've used a loop inside a spinlock-protected critical section, > which is against project

Re: [HACKERS] Parallel Append implementation

10, 06, 08), the times remaining are : 4 0 0 2 3 1 After 2 units (minimum of 4, 2, 3), the times remaining are : 2 0 0 0 1 1 After 1 units (minimum of 2, 1, 1), the times remaining are : 1 0 0 0 0 0 After 1 units (minimum of 1, 0 , 0), the times remaining are : 0 0 0 0 0 0 Now add up above time

Re: [HACKERS] UPDATE of partition key

the core part and leave the rest to be done by ExecUpdate() itself. Yes, if we decide to execute only the core insert/delete operations and skip the triggers, then there is a compelling reason to have something like ExecDeleteInternal() and ExecInsertInternal(). In fact, I was about to start doing the same, except f

Re: [HACKERS] Parallel Append implementation

nd option 1 is also an approximation but we would like to have a better approximation. So wanted to clear my queries regarding option 3. -- Details about all the remaining changes in updated patch are below ... On 20 March 2017 at 17:29, Robert Haas <robertmh...@gmail.com> wrote: > On Fri

Re: [HACKERS] Parallel Append implementation

On 12 March 2017 at 08:50, Robert Haas wrote: >> However, Ashutosh's response made me think of something: one thing is >> that we probably do want to group all of the non-partial plans at the >> beginning of the Append so that they get workers first, and put the >> partial

Re: [HACKERS] Parallel Append implementation

plexity with the > parallel append case. Each worker there does the same kind of work, and > if one of them is behind, it'll just do less. But correct sizing will > be more important with parallel-append, because with non-partial > subplans the work is absolutely *not* uniform. >

Re: [HACKERS] Parallel Append implementation

is not valid. But I think till then we should follow some common strategy we have been following. BTW all of the above points apply only for non-partial plans. For partial plans, what we have done in the patch is : Take the highest of the per-subplan parallel_workers, and make sure that Append w

Re: [HACKERS] Parallel Append implementation

On 4 April 2017 at 01:47, Andres Freund wrote: >> +typedef struct ParallelAppendDescData >> +{ >> + LWLock pa_lock;/* mutual exclusion to choose >> next subplan */ >> + int pa_first_plan; /* plan to choose while >>

Re: [HACKERS] UPDATE of partition key

On 3 April 2017 at 17:13, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Amit, > > Thanks for updating the patch. Since ddl.sgml got updated on Saturday, > patch needs a rebase. Rebased now. > >> On 31 March 2017 at 16:54, Amit Khandekar <amitdkhan...@gma

Re: [HACKERS] UPDATE of partition key

For some reason, my reply got sent to only Amit Langote instead of reply-to-all. Below is the mail reply. Thanks Amit Langote for bringing this to my notice. On 31 March 2017 at 16:54, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 31 March 2017 at 14:04, Amit Langote <

Re: [HACKERS] Parallel Append implementation

On 7 April 2017 at 20:35, Andres Freund wrote: >> But for costs such as (4, 4, 4, 20 times), the logic would give >> us 20 workers because we want to finish the Append in 4 time units; >> and this what we want to avoid when we go with >> don't-allocate-too-many-workers

Re: [HACKERS] Parallel Append implementation

they run with (2, 1, 1). So now the next_plan points to plan 2. Now suppose worker on plan 2 finishes. It should not again take plan 2, even though next_plan points to 2. It should take plan 3, or whichever is not finished. May be a worker that finishes a plan should do this check before directly going to t

Re: [HACKERS] Parallel Append implementation

it as -1, so that no new workers pick this, even if there are other workers already executing it. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database 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] Parallel Append implementation

. * For non-partial plans, set it to -1 instead, so that no other workers * run it. */ if (min_whichplan != PA_INVALID_PLAN) { if (bms_is_member(min_whichplan, ((Append*)state->ps.plan)->partial_subplans_set)) padesc->pa_info[min_whichplan].pa_num_workers++; else

Re: [HACKERS] Parallel Append implementation

After giving more thought to our discussions, I have have used the Bitmapset structure in AppendPath as against having two lists one for partial and other for non-partial paths. Attached is the patch v6 that has the required changes. So accumulate_append_subpath() now also prepares the bitmapset

Re: [HACKERS] Parallel Append implementation

On 10 March 2017 at 22:08, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Mar 10, 2017 at 12:17 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> I agree that the two-lists approach will consume less memory than >> bitmapset. Keeping two lists will eff

Re: [HACKERS] Parallel Append implementation

called with the number of currently running workers, > the max. number of workers to be expected, the new worker, the list of > plans still todo, and then schedules that single worker to one of these > plans by strategy X. > > That would make it easier to swap out X for Y and

Re: [HACKERS] Parallel Append implementation

On 19 February 2017 at 14:59, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Feb 17, 2017 at 2:56 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> The log2(num_children)+1 formula which you proposed does not take into >> account the number of workers fo

Re: [HACKERS] Parallel Append implementation

On 6 April 2017 at 07:33, Andres Freund <and...@anarazel.de> wrote: > On 2017-04-05 14:52:38 +0530, Amit Khandekar wrote: >> This is what the earlier versions of my patch had done : just add up >> per-subplan parallel_workers (1 for non-partial subplan and >> subpath-&g

Re: [HACKERS] map_partition_varattnos() and whole-row vars

RETURNING) can have a subquery. > > Thanks, > Amit > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Thanks, -Amit Khandekar EnterpriseDB Corporat

Re: [HACKERS] UPDATE of partition key

On 2 August 2017 at 14:38, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/07/29 2:45, Amit Khandekar wrote: >> On 28 July 2017 at 20:10, Robert Haas <robertmh...@gmail.com> wrote: >>> On Wed, Jul 26, 2017 at 2:13 AM, Amit Langote wrote: >>>

Re: [HACKERS] map_partition_varattnos() and whole-row vars

On 3 August 2017 at 11:00, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Thanks for the review. > > On 2017/08/03 13:54, Amit Khandekar wrote: >> On 2 August 2017 at 11:51, Amit Langote wrote: >>> On 2017/08/02 1:33, Amit Khandekar wrote: >>>> Ins

Re: [HACKERS] map_partition_varattnos() and whole-row vars

On 2 August 2017 at 11:51, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Thanks Fuita-san and Amit for reviewing. > > On 2017/08/02 1:33, Amit Khandekar wrote: >> On 1 August 2017 at 15:11, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: >>> On

  1   2   >