Re: [HACKERS] Runtime Partition Pruning

On 2018/04/13 14:48, Amit Langote wrote: > On 2018/04/13 14:38, Amit Langote wrote: >> About the specific relation_open(.., NoLock) under question, I think there >> might be a way to address this by opening the tables with the appropriate >> lock mode in

Re: [HACKERS] path toward faster partition pruning

On 2018/04/13 1:47, Robert Haas wrote: > On Wed, Apr 11, 2018 at 8:35 AM, Alvaro Herrera > wrote: >> Here's an idea. Why don't we move the function/opclass creation lines >> to insert.sql, without the DROPs, and use the same functions/opclasses >> in the three tests

Re: Boolean partitions syntax

Horiguchi-san, Thanks for the latest patch. On 2018/04/12 13:12, Kyotaro HORIGUCHI wrote: > Thank you for verification and the revised patch. The format is > fine and the fix is correct but I noticed that I forgot to remove > plural S's from error messages. The attached is the version with > the

Re: crash with sql language partition support function

On 2018/04/13 3:10, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> I'm dealing with this now -- will push shortly. The sane thing to do is >> backpatch my previous memcxt fixes, since your patch introduces a >> problem that we discussed with that other patch, namely that you would >> leak

Re: wal_consistency_checking reports an inconsistency on master branch

On 2018/04/13 19:08, Michael Paquier wrote: > On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote: >> I have looked into this and found that the issue is in heap_xlog_delete -- we >> have missed to set the correct offset number from the target_tid when >> XLH_DELETE_IS_PARTITION_MOVE flag is

Re: wal_consistency_checking reports an inconsistency on master branch

On 2018/04/13 7:36, Peter Geoghegan wrote: > On Thu, Apr 12, 2018 at 11:47 AM, Peter Geoghegan wrote: >> In short, it looks like the tests added to update.sql by commit >> 2f178441 ("Allow UPDATE to move rows between partitions") lead to this >> failure, since I always hit a problem

Re: [HACKERS] path toward faster partition pruning

On Fri, Apr 6, 2018 at 11:38 PM, Alvaro Herrera wrote: > Yeah, there is one sentence there I didn't quite understand and would > like to add it to the rewritten version of the comment before I remove > the whole ifdeffed-out comment. > > * PARTCLAUSE_MATCH_STEPS:

Re: [HACKERS] path toward faster partition pruning

On Fri, Apr 6, 2018 at 11:54 PM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> Yeah. Looking at this function, I noticed it tests for BooleanTest, and >> falls back to checking "not_clause" and a few equals. Does it make >> sense if the clause is a SAOP? I added

Re: [HACKERS] path toward faster partition pruning

On Sat, Apr 7, 2018 at 1:41 AM, Alvaro Herrera wrote: > Here's my proposed patch. > > Idle thought: how about renaming the "constfalse" argument and variables > to "contradictory" or maybe just "contradict"? Sounds fine to me. Thanks, Amit

Re: [HACKERS] Runtime Partition Pruning

On 2018/04/11 6:32, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera >> wrote: > I don't get this. The executor surely had to (and did) open all of the relations somewhere even before this patch. > >>> I was

Re: [HACKERS] path toward faster partition pruning

On 2018/04/11 21:35, Alvaro Herrera wrote: > Here's an idea. Why don't we move the function/opclass creation lines > to insert.sql, without the DROPs, and use the same functions/opclasses > in the three tests insert.sql, alter_table.sql, hash_part.sql and > partition_prune.sql, i.e. not recreate

Re: relispartition for index partitions

On 2018/04/12 5:33, Alvaro Herrera wrote: > Amit Langote wrote: >> Hi. >> >> I noticed that relispartition isn't set for index's partitions. > > This patch should fix it. Thanks. I saw your commit 9e9befac4a22 and changes seem fine. Regards, Amit

Re: Boolean partitions syntax

On 2018/04/11 10:44, Tom Lane wrote: > Kyotaro HORIGUCHI writes: >> At least partition bound *must* be a constant. Any expression >> that can be reduced to a constant at parse time ought to be >> accepted but must not be accepted if not. > > My point is that

Re: Partitioned tables and covering indexes

Hi. On 2018/04/11 0:36, Teodor Sigaev wrote: >>     Does the attached fix look correct?  Haven't checked the fix with >> ATTACH >>     PARTITION though. >> >> >> Attached patch seems to fix the problem.  However, I would rather get >> rid of modifying stmt->indexParams.  That seems to be more

Re: Boolean partitions syntax

On 2018/04/10 23:37, David Rowley wrote: > On 10 April 2018 at 23:13, Kyotaro HORIGUCHI > wrote: >> Note: This is not intended to be committed this time but just for >> information. >> >> At Tue, 10 Apr 2018 10:34:27 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI

Re: partitioning code reorganization

On Sun, Apr 15, 2018 at 11:57 AM, Amit Langote <amitlangot...@gmail.com> wrote: > On Sun, Apr 15, 2018 at 9:17 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: >> Thanks! I pushed this now, putting back the enum in parsenodes and >> including this delta patc

Re: partitioning code reorganization

On Sun, Apr 15, 2018 at 9:17 AM, Alvaro Herrera wrote: > Thanks! I pushed this now, putting back the enum in parsenodes and > including this delta patch of yours. Thank you. Do you think the following CF entry is good to be closed? Regards, Amit

Re: Oddity in tuple routing for foreign partitions

On 2018/04/17 11:13, Kyotaro HORIGUCHI wrote: >>> Also, I removed the CheckValidResultRel check from ExecInitRoutingInfo >>> and added that to ExecInitPartitionInfo right after the> InitResultRelInfo >>> call, >>> because it would be better to abort the >>> operation as soon as we find the

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/17 4:10, Alvaro Herrera wrote: > Amit Langote wrote: > >> The solution I came up with is to call map_variable_attnos() directly, >> instead of going through map_partition_varattnos() every time, after first >> creating the attribute map ourselves. > &g

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/17 16:45, Amit Langote wrote: > Instead of doing this, I think we should try to make > convert_tuples_by_name_map() a bit smarter by integrating the logic in > convert_tuples_by_name() that's used conclude if no tuple conversion is > necessary. So, if it turns tha

Re: pruning disabled for array, enum, record, range type partition keys

On Thu, Apr 19, 2018 at 12:01 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Amit Langote wrote: > >> On 2018/04/18 7:11, Alvaro Herrera wrote: >> >> @@ -1546,8 +1546,8 @@ match_clause_to_partition_key(RelOptInfo *rel, >>case PARTITION_STRATEGY_HASH

Re: Boolean partitions syntax

ion ‘get_partition_col_collation’: src/include/utils/rel.h:594:12: error: dereferencing pointer to incomplete type ‘struct PartitionKeyData’ PartitionKeyData definition was recently moved to partcache.h as part of the big partition code reorganization. > At Fri, 13 Apr 2018 18:55:30 +0900, Amit L

Re: Oddity in tuple routing for foreign partitions

On 2018/04/17 16:41, Etsuro Fujita wrote: > In the INSERT/COPY-tuple-routing case, as explained by Amit, the > RTE at that position in the EState's range table is the one for the > partitioned table of a given partition, so the statement would be true.  > BUT in the UPDATE-tuple-routing case, the

Re: partitioning code reorganization

On 2018/04/18 5:18, Alvaro Herrera wrote: > Amit Langote wrote: > >> 0001-Make-copying-of-cached-partitioning-info-more-con.patch >> 0002-Cache-all-partitioning-info-under-one-memory-cont.patch >> 0003-Cache-partsupfunc-separately-from-PartitionKey.patch > > I'd r

Re: Boolean partitions syntax

On 2018/04/18 19:27, Amit Langote wrote: > Please find attached an updated version of your patch. I think we'll need > to make some documentation changes and think about a way to back-patch > this to PG10. Added documentation changes. Also, noticed that there was no need

Re: [HACKERS] Runtime Partition Pruning

Hi David. On 2018/04/19 9:04, David Rowley wrote: > On 19 April 2018 at 03:13, Robert Haas wrote: >> On Mon, Apr 16, 2018 at 10:46 PM, David Rowley >> wrote: >>> The patch does happen to improve performance slightly, but that is >>> most

Re: partitioning code reorganization

On 2018/04/15 9:17, Alvaro Herrera wrote: > Amit Langote wrote: >> On Sat, Apr 14, 2018 at 11:48 PM, Amit Langote <amitlangot...@gmail.com> >> wrote: >>> Hi. >>> >>> Thanks for taking care of few things I left like those PartitionKey

Re: pruning disabled for array, enum, record, range type partition keys

Hi. On 2018/04/19 6:45, Alvaro Herrera wrote: > Amit Langote wrote: >> On Thu, Apr 19, 2018 at 12:01 AM, Alvaro Herrera >> <alvhe...@alvh.no-ip.org> wrote: > >>> Makes sense. Still, I was expecting that pruning of hash partitioning >>> would

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/04/19 21:50, Ashutosh Bapat wrote: > On Thu, Apr 19, 2018 at 5:02 PM, Amit Langote >> I can imagine having a enable_partition_pruning which defaults to true, if >> only to avoid the performance overhead of pruning code when a user knows >> for sure that it won't

Re: Should we add GUCs to allow partition pruning to be disabled?

Hi. On 2018/04/20 11:18, David Rowley wrote: > On 20 April 2018 at 14:07, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> To clarify: if we're going to add a new parameter *for partitioned tables* >> to configure whether or not pruning occurs, even if UPDATE a

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/04/20 15:00, Ashutosh Bapat wrote: > On Fri, Apr 20, 2018 at 7:37 AM, Amit Langote wrote: >> On 2018/04/19 21:50, Ashutosh Bapat wrote: >>> There's no point in confusing users >>> with by adding dependencies between these two GUCs. >> >> Th

Re: Should we add GUCs to allow partition pruning to be disabled?

Hi David. Thanks for writing the patch. On 2018/04/20 14:47, David Rowley wrote: > On 20 April 2018 at 14:07, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> To clarify: if we're going to add a new parameter *for partitioned tables* >> to configure whether or not

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/04/20 17:51, Amit Langote wrote: > On 2018/04/20 14:47, David Rowley wrote: >> On 20 April 2018 at 14:07, Amit Langote <langote_amit...@lab.ntt.co.jp> >> wrote: >>> To clarify: if we're going to add a new parameter *for partitioned tables* >>> to

Re: Boolean partitions syntax

On 2018/04/19 20:35, Kyotaro HORIGUCHI wrote: > At Wed, 18 Apr 2018 19:27:16 +0900, Amit Langote wrote: >> On 2018/04/16 16:17, Kyotaro HORIGUCHI wrote: >>> It was a bother that some rules used c_expr directly but I >>> managed to replace all of them with a_expr by lowe

Re: Oddity in tuple routing for foreign partitions

On 2018/04/25 4:49, Robert Haas wrote: > On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote: >> On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera >> wrote: >>> Robert, I think this is your turf, per 3d956d9562aa. Are you looking >>> into it? >> >>

Re: Minor comment update in execPartition.c

Fujita-san, On 2018/04/24 20:14, Etsuro Fujita wrote: > Hi, > > Here is a comment for ExecInitPartitionInfo: > > 296 * ExecInitPartitionInfo > 297 * Initialize ResultRelInfo and other information for a > partition if not > 298 * already done > > I think we should remove the

Re: Oddity in tuple routing for foreign partitions

Oops, really meant to send the "+1 to the root -> rte refactoring" comment and the rest in the same email. On 2018/04/25 4:49, Robert Haas wrote: > I have done some refactoring to avoid that. See attached. > > I didn't really get beyond the refactoring stage with this today. > This version

using expression syntax for partition bounds (was: Re: Boolean partitions syntax)

(patch and discussion for PG 12) On 2018/04/22 1:28, Tom Lane wrote: > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >> [ v8-0001-Allow-generalized-expression-syntax-for-partition.patch ] > > I find what you did to a_expr here to be pretty horrid. Thanks for the re

Re: using expression syntax for partition bounds (was: Re: Boolean partitions syntax)

On 2018/04/23 11:37, Amit Langote wrote: > I tried to update the patch to do things that way. I'm going to create a > new entry in the next CF titled "generalized expression syntax for > partition bounds" and add the patch there. Tweaked the commit message to credit all t

description of root_tuple_slot missing

I noticed that the description of root_tuple_slot member is missing in the comment above PartitionTupleRouting definition. See if the attached patch fixes it correctly. Thanks, Amit diff --git a/src/include/executor/execPartition.h b/src/include/executor/execPartition.h index

Re: [HACKERS] path toward faster partition pruning

On 2018/04/21 0:58, Alvaro Herrera wrote: > Amit Langote wrote: > >> PS: git grep "partition by hash\|PARTITION BY HASH" on src/test indicates >> that there are hash partitioning related tests in create_table, >> foreign_key, and partition_join files as well

Re: Boolean partitions syntax

On 2018/04/22 2:29, Tom Lane wrote: > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >> I think if this bug/open item can be resolved by adopting the minimal >> patch, then we should use it for that. Maybe, we can discuss the rest of >> the changes independently.

Re: Should we add GUCs to allow partition pruning to be disabled?

Hi David. On 2018/04/21 14:09, David Rowley wrote: > On 20 April 2018 at 20:51, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> set constraint_exclusion to off; >> >> -- not ok! > > It needed a bit more effort than I put in the first time ar

minor fix for CloneRowTriggersToPartition

Hi. I think we should apply the attached patch so that a CreateTriggerStmt that CloneRowTriggersToPartition creates for a partition doesn't contain pointers that point to the information in the parent table's relcache, which may go stale before the pointers in question are used. Thanks, Amit

minor fix for acquire_inherited_sample_rows

Hi. acquire_inherited_sample_rows() currently uses equalTupleDescs() being false as the condition for going to tupconv.c to determine whether tuple conversion is needed. But equalTupleDescs() will always return false if it's passed TupleDesc's of two different tables, which is the most common

Re: minor fix for acquire_inherited_sample_rows

Thanks for the review. On Mon, Apr 23, 2018 at 8:25 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Mon, Apr 23, 2018 at 3:44 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Hi. >> >> acquire_inherited_sample_rows() currently u

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/04/24 6:10, Alvaro Herrera wrote: >> BTW, while we're at it, would it also be a good idea to consider the patch >> you had proposed, which I then posted an updated version of, to adjust the >> documentation in ddl.sgml (in the section 5.10. Table Partitioning) >> regarding the relationship

Re: minor fix for acquire_inherited_sample_rows

On 2018/04/24 13:29, Ashutosh Bapat wrote: > On Mon, Apr 23, 2018 at 6:45 PM, Amit Langote <amitlangot...@gmail.com> wrote: >> On Mon, Apr 23, 2018 at 8:25 PM, Ashutosh Bapat wrote: >>> On Mon, Apr 23, 2018 at 3:44 PM, Amit Langote wrote: >>>> Hi. >

Re: Oddity in tuple routing for foreign partitions

Fujita-san, On 2018/04/16 20:25, Etsuro Fujita wrote: > Hi, > > While updating the fix-postgres_fdw-WCO-handling patch, I noticed that > the patch for tuple routing for foreign partitions doesn't work well > with remote triggers. Here is an example: > > postgres=# create table loct1 (a int

Re: pruning disabled for array, enum, record, range type partition keys

Thanks for the review. On 2018/04/18 7:11, Alvaro Herrera wrote: > Amit Langote wrote: > >> Ah, I think I got it after staring at the (btree) index code for a bit. >> >> What pruning code got wrong is that it's comparing the expression type >> (type of the cons

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/10 11:56, Amit Langote wrote: > On 2018/03/27 13:27, Amit Langote wrote: >> On 2018/03/26 23:20, Alvaro Herrera wrote: >>> The one thing I wasn't terribly in love with is the four calls to >>> map_partition_varattnos(), creating the attribute map four times

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/18 0:02, Alvaro Herrera wrote: > Amit Langote wrote: > >> Attached find a patch that does that. When working on this, I noticed >> that when recursing for inheritance children, ATPrepAlterColumnType() >> would use a AlterTableCmd (cmd) that's already sc

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/18 22:40, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2018/04/18 0:04, Alvaro Herrera wrote: >>> Amit Langote wrote: >>> >>>> I just confirmed my hunch that this wouldn't somehow do the right thing >>>> when the OID system colu

Re: Oddity in tuple routing for foreign partitions

Fujita-san, Thanks for the updated patch. On 2018/04/19 21:42, Etsuro Fujita wrote: > (2018/04/19 16:43), Amit Langote wrote: >> Would it be a good idea to explain *why* we need to replace the RTE in the >> first place?  Afaics, it's for deparseColumnRef() to find the correct &

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/20 4:40, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Amit Langote wrote: >> >>> Yeah, I too have wondered in the past what it would take to make >>> equalTupDescs() return true for parent and partitions. Maybe we can make >>>

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/03/26 23:20, Alvaro Herrera wrote: > Pushed now. Thank you! > Amit Langote wrote: >> On 2018/03/24 9:23, Alvaro Herrera wrote: > >>> To fix this, I had to completely rework the "get partition parent root" >>> stuff into "get list o

Re: Oddity in COPY FROM handling of check constraints on partition tables

Fujita-san, On 2018/03/27 22:00, Etsuro Fujita wrote: > Hi, > > While updating the tuple-routing-for-foreign-partitions patch, I noticed > oddity in the COPY FROM handling of check constraints on partition > tables. Here is an example: > > postgres=# create table pt (a int, b int) partition by

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

On 2018/03/30 17:31, Kyotaro HORIGUCHI wrote: > At Thu, 29 Mar 2018 13:04:06 -0300, Alvaro Herrera wrote: >> Rushabh Lathia wrote: >>> On Thu, Mar 29, 2018 at 7:46 PM, Alvaro Herrera >>> wrote: >> Hmm, offhand I don't quite see why this error fails to be thrown. >>>

Re: [HACKERS] path toward faster partition pruning

On 2018/03/30 22:41, David Rowley wrote: > On 31 March 2018 at 02:00, David Rowley wrote: >> On 31 March 2018 at 01:18, David Rowley wrote: >>> I've noticed that there are no outfuncs or readfuncs for all the new >>> Step types you've

Re: JIT compiling with LLVM v12

On 2018/03/29 9:35, Michael Paquier wrote: > On Wed, Mar 28, 2018 at 06:24:53PM -0400, David Steele wrote: >> On 3/28/18 6:09 PM, Andres Freund wrote: >>> Hah! Happy to, if there's enough people interested. I've a talk about >>> it too (state of jit, 2018 edition), but I wasn't planning to go

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Thanks Jeevan for reviewing. On 2018/04/02 13:10, Jeevan Ladhe wrote: > Hi, > > I noticed that there were no tests covering this case causing 4dba331cb3 >> to not notice this failure in the first place. I updated your patch to >> add a few tests. Also, I revised the comment changed by your

Re: [HACKERS] Add support for tuple routing to foreign partitions

Fujita-san, Thanks for updating the patch. On 2018/03/30 21:56, Etsuro Fujita wrote: > I modified the patch to use the existing API ExecForeignInsert instead of > that API and removed that API including this doc. OK. >> 2. If I understand the description you provided in [1] correctly, the >>

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2018/04/02 21:26, Etsuro Fujita wrote: > (2018/03/30 22:28), Alvaro Herrera wrote: >> Etsuro Fujita wrote: >> >>> Now we have ON CONFLICT for partitioned tables, which requires the >>> conversion map to be computed in ExecInitPartitionInfo, so I updated the >>> patch so that we keep the former

Re: [HACKERS] Add support for tuple routing to foreign partitions

Fujita-san, On 2018/04/02 21:29, Etsuro Fujita wrote: > (2018/04/02 18:49), Amit Langote wrote: >> I looked at the new patch.  It looks good overall, although I have one >> question -- IIUC, BeginForeignInsert() performs actions that are >> equivalent of perform

Re: open/lseek overhead with many partitions (including with "faster partitioning pruning")

Hi Justin. On 2018/04/04 4:46, Justin Pryzby wrote: > TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file > backing every table being queried, even for those partitions eventually > "excluded". That's expected. The faster pruning patch doesn't change the behavior with

Re: open/lseek overhead with many partitions (including with "faster partitioning pruning")

On 2018/04/04 9:27, David Rowley wrote: > On 4 April 2018 at 07:46, Justin Pryzby wrote: >> TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file >> backing every table being queried, even for those partitions eventually >> "excluded". > > Yeah, this

Re: [HACKERS] Runtime Partition Pruning

Hi David. On 2018/04/04 11:10, David Rowley wrote: > On 4 April 2018 at 05:44, Jesper Pedersen wrote: >> Also, I'm seeing a regression for check-world in >> src/test/regress/results/inherit.out >> >> *** >> *** 642,648 >>

Re: [HACKERS] path toward faster partition pruning

Thanks Tomas for the review. On 2018/03/30 1:55, Tomas Vondra wrote: > Hi, > > I think there's a bug in generate_pruning_steps_from_opexprs, which does > this for PARTITION_STRATEGY_HASH: > > > for_each_cell(lc1, lc) > { > pc = lfirst(lc1); > > /* > * Note

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/03/24 9:23, Alvaro Herrera wrote: > I made a bunch of further edits and I think this v10 is ready to push. > Before doing so I'll give it a final look, particularly because of the > new elog(ERROR) I added. Post-commit review is of course always > appreciated. > > Most notable change is

Re: [HACKERS] Runtime Partition Pruning

On 2018/04/04 16:04, David Rowley wrote: > On 4 April 2018 at 18:27, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> I'm not sure if we've yet discussed anything that'd be related to this on >> the faster pruning thread. > > hmm, yeah, I didn't really explain

Re: [HACKERS] path toward faster partition pruning

Hi David. On 2018/03/19 16:18, David Rowley wrote: > On 17 March 2018 at 01:55, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Hope the attached version is easier to understand. > > Hi Amit, > > Thanks for making the updates. I'll look at them soon. >

Re: [HACKERS] Add support for tuple routing to foreign partitions

Fujita-san, Thanks for sending the updated patches. On 2018/02/27 21:01, Etsuro Fujita wrote: > (2018/02/21 20:54), Etsuro Fujita wrote: >> void >> BeginForeignRouting(); >> >> Prepare for a tuple-routing operation on a foreign table. This is called >> from ExecSetupPartitionTupleRouting and

Re: ON CONFLICT DO UPDATE for partitioned tables

0 Mar 2018 10:09:38 +0900 Subject: [PATCH v6] Fix ON CONFLICT to work with partitioned tables Author: Amit Langote, Alvaro Herrera, Etsuro Fujita --- doc/src/sgml/ddl.sgml | 15 -- src/backend/catalog/heap.c| 2 +- src/backend/catalog/partition.c | 62

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/03/20 13:30, Amit Langote wrote: > I have incorporated your patch in the main patch after updating the > comments a bit. Also, now that ee49f49 is in [1], the transition > table related tests I proposed yesterday pass nicely. Instead of posting > as a separate patch, I

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2018/03/19 20:25, Amit Langote wrote: > That's all I have for now. While testing this patch, I noticed a crash when performing EXPLAIN on update of a partition tree containing foreign partitions. Crash occurs in postgresEndForeignRouting() due to the following Assert failing: Ass

Re: constraint exclusion and nulls in IN (..) clause

On 2018/03/21 23:00, Tom Lane wrote: > Emre Hasegeli writes: >> I am not sure if we are covering the case when clause_const and >> pred_const are both NULL. In this case, we should be able to return >> true only by checking op_strict(pred_op) or maybe even without >> checking

Re: ON CONFLICT DO UPDATE for partitioned tables

> + TupleTableSlot *slot, > + int *partition_index); > static ResultRelInfo *getTargetResultRelInfo(ModifyTableState *node); > static void ExecSetupChildParentMapForTcs(ModifyTableState *mtstate); > static void ExecSetupChildParentMapForSubplan(ModifyTableState *mtstate); > @@ -264,6 +266,7 @@ ExecInsert(

Re: inserts into partitioned table may cause crash

On 2018/03/20 5:54, Alvaro Herrera wrote: > Etsuro Fujita wrote: > >> Thanks for the updated patches! I think the patches are in good shape, but >> I did a bit of editorial things; added a bit more comments for >> ExecPrepareTupleRouting and adjusted regression test stuff to match the >>

Re: [HACKERS] path toward faster partition pruning

On 2018/03/20 21:41, David Rowley wrote: > On 21 March 2018 at 00:07, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Attached is further revised version. > > In the 0004 patch I see: > > @@ -1439,6 +1441,10 @@ inheritance_planner(PlannerInfo *root) &g

Re: Boolean partitions syntax

Hi David. On 2018/03/21 23:31, David Steele wrote: > Hi Amit, > > On 3/6/18 9:44 AM, David Steele wrote: >> On 3/2/18 2:27 AM, Amit Langote wrote: >>> On 2018/03/02 15:58, Andres Freund wrote: >>>> On 2018-02-02 17:00:24 -0500, Tom Lane wrote: &

Re: ON CONFLICT DO UPDATE for partitioned tables

om> Date: Tue, 20 Mar 2018 10:09:38 +0900 Subject: [PATCH v9] Fix ON CONFLICT to work with partitioned tables Author: Amit Langote, Alvaro Herrera, Etsuro Fujita --- doc/src/sgml/ddl.sgml | 15 -- doc/src/sgml/ref/insert.sgml | 8 + src/bac

Re: TOAST table created for partitioned tables

On 2018/03/23 2:51, Robert Haas wrote: > On Wed, Jan 17, 2018 at 1:03 AM, Amit Langote <amitlangot...@gmail.com> wrote: >> On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> On Tue, Jan 16, 2018 at 11:38:58PM -0500, T

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/03/23 3:42, Pavan Deolasee wrote: > A slightly improved version attached. Apart from doc cleanup based on > earlier feedback, fixed one assertion failure based on Rahila's report. > This was happening when target relation is referenced in the source > subquery. Fixed that and added a test

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/03/23 13:57, Pavan Deolasee wrote: > On Fri, Mar 23, 2018 at 10:00 AM, Amit Langote wrote: >> I managed to apply it by ignoring the errors, but couldn't get make check >> to pass; attached regressions.diffs if you want to take a look. > > Thanks. Are you sure you're

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/03/23 20:07, Pavan Deolasee wrote: > On Fri, Mar 23, 2018 at 12:57 PM, Amit Langote wrote: >> Also, it seems that the delta patch I sent in the last email didn't >> contain all the changes I had to make. It didn't contain, for example, >> replacing adjust_and_e

Re: ON CONFLICT DO UPDATE for partitioned tables

Thanks for the updated patches. On 2018/03/18 13:17, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> I think what I should be doing is the same as the returning stuff: keep >> a tupdesc around, and use a single slot, whose descriptor is changed >> just before the projection. > > Yes, this

Re: inserts into partitioned table may cause crash

Fujita-san, Thanks for the review. On 2018/03/16 20:37, Etsuro Fujita wrote: > (2018/03/14 17:25), Etsuro Fujita wrote: >> (2018/03/14 14:54), Amit Langote wrote: >>> Btw, I noticed that the patches place ExecPrepareTupleRouting (both the >>> declaration and the defini

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/03/19 16:45, Amit Langote wrote: > I have tried to make these changes and attached are the updated patches > containing those, including the change I suggested for 0001 (that is, > getting rid of mt_onconflict). I also expanded some comments in 0003 > while making those

Re: [HACKERS] path toward faster partition pruning

Thanks for the review. On 2018/03/21 6:29, Robert Haas wrote: > On Tue, Mar 20, 2018 at 7:07 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2018/03/16 21:55, Amit Langote wrote: >>> Attached updated patches. >> >> Attached is further revise

Re: [HACKERS] path toward faster partition pruning

On 2018/03/03 0:47, Robert Haas wrote: > On Fri, Mar 2, 2018 at 6:21 AM, Amit Langote wrote: >> Given the patch's implementation, we'll have to make the structure of that >> Node tree a bit more complex than a simple List. For one thing, the patch >> handles OR clauses

Re: non-bulk inserts and tuple routing

On 2018/03/03 13:38, Andres Freund wrote: > Hi, > > On 2018-02-22 11:10:57 -0500, Robert Haas wrote: >> On Tue, Feb 20, 2018 at 8:06 PM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>>> Attached is an updated version for that. >>> &g

Re: constraint exclusion and nulls in IN (..) clause

Hi. On 2018/03/04 22:12, Emre Hasegeli wrote: >> Yeah, the patch in its current form is wrong, because it will give wrong >> answers if the operator being used in a SAOP is non-strict. I modified >> the patch to consider operator strictness before doing anything with nulls. > > I tried to

Re: non-bulk inserts and tuple routing

On 2018/03/03 13:48, Andres Freund wrote: > On 2018-02-22 11:10:57 -0500, Robert Haas wrote: >> On Tue, Feb 20, 2018 at 8:06 PM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>>> Attached is an updated version for that. >>> >>> Thanks

Re: [HACKERS] path toward faster partition pruning

On 2018/03/02 21:43, Robert Haas wrote: > On Fri, Mar 2, 2018 at 1:22 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> But I realized we don't need the coercion. Earlier steps would have >> determined that the clause from which the expression originated

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/03/03 0:36, Alvaro Herrera wrote: > Amit Langote wrote: > >> Actually, after your comment on my original patch [1], I did make it work >> for multiple levels by teaching the partition initialization code to find >> a given partition's indexes that are inher

Re: Re: reorganizing partitioning code

Hi David. On Fri, Mar 2, 2018 at 11:53 PM, David Steele <da...@pgmasters.net> wrote: > Hi Amit, > > On 2/16/18 3:36 AM, Amit Langote wrote: >> >> Attached updated version. > > This patch no longer applies and the conflicts do not appear to be trivial. > >

Re: [HACKERS] path toward faster partition pruning

On 2018/02/27 3:27, Robert Haas wrote: > On Sun, Feb 25, 2018 at 11:10 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> I think I'm convinced that partopcintype OIDs can be used where I thought >> parttypid ones were necessary. The pruning patch uses th

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/02/28 9:46, Alvaro Herrera wrote: > I updated Amit Langote's patch for INSERT ON CONFLICT DO UPDATE[1]. > Following the lead of edd44738bc88 ("Be lazier about partition tuple > routing.") this incarnation only does the necessary push-ups for the > specific partition that needs it, at

inserts into partitioned table may cause crash

I've run into what seems to be a bug in ExecInsert() that causes a crash when inserting multiple rows into a partitioned table that each go into different partitions with different tuple descriptors. Crash occurs if ExecInsert() returns without resetting estate->es_result_relation_info back to

Re: inserts into partitioned table may cause crash

On 2018/02/28 17:36, Amit Langote wrote: > I've run into what seems to be a bug in ExecInsert() that causes a crash > when inserting multiple rows into a partitioned table that each go into > different partitions with different tuple descriptors. Crash occurs if > ExecInsert() ret

<    1   2   3   4   5   6   7   8   9   10   >