Re: why partition pruning doesn't work?

On 2018/07/16 2:02, Tom Lane wrote: > Amit Langote writes: >> On 2018/06/19 2:05, Tom Lane wrote: >>> Or maybe what we should do is drop ExecLockNonLeafAppendTables/ >>> ExecOpenAppendPartitionedTables entirely and teach InitPlan to do it. > &

Re: Speeding up INSERTs and UPDATEs to partitioned tables

Hi David, Thanks for taking a look. On 2018/07/15 17:34, David Rowley wrote: > I've looked over the code and the ExecUseUpdateResultRelForRouting() > function is broken. Your while loop only skips partitions for the > current partitioned table, it does not skip ModifyTable subnodes that >

Re: How to make partitioning scale better for larger numbers of partitions

On 2018/07/13 22:10, Ashutosh Bapat wrote: > On Fri, Jul 13, 2018 at 9:23 AM, Kato, Sho wrote: >>> I wondered if you compared to PG10 or to inheritence-partitioning (parent >>> with relkind='r' and either trigger or rule or >INSERT/UPDATE directly into >>> child) ? >> >> Thank you for your

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

On 2018/07/17 8:17, Alvaro Herrera wrote: > On 2018-Jul-16, Ashutosh Bapat wrote: > >>> Hmm, let me reword this comment completely. How about the attached? > >> That looks much better. However it took me a small while to understand >> that (1), (2) and (3) correspond to strategies. > > You're

Re: pgsql: Allow UNIQUE indexes on partitioned tables

On 2018/07/17 13:57, Alvaro Herrera wrote: > On 2018-Feb-19, David G. Johnston wrote: > >> As an aside, adding a link to "Data Definiton/Table Partitioning" from at >> least CREATE TABLE ... PARTITION BY; and swapping "PARTITION BY" and >> "PARTITION OF" in the Parameters section of that page -

Re: cached plans and enable_partition_pruning

On Mon, Jul 23, 2018 at 11:20 PM, Andres Freund wrote: > Hi, > > On 2018-07-23 18:31:43 +0900, Amit Langote wrote: >> It seems that because enable_partition_pruning's value is only checked >> during planning, turning it off *after* a plan is created and cached does &g

Re: [report] memory leaks in COPY FROM on partitioned table

Hi Kaigai-san, Thanks for the report and the patch. On 2018/07/24 11:43, Kohei KaiGai wrote: > Further investigation I did: > > CopyFrom() calls ExecFindPartition() to identify the destination child > table of partitioned table. > Then, it internally calls get_partition_for_tuple() to get

Re: code of partition split

Hi. On 2018/07/23 12:08, Chenxi Li wrote: > Hi hackers, > > I'm interested in partition split and want to figure out how it works. > Could someone tell me where the code is located? Thanks very much. Can you tell what you mean by "partition split"? I don't know of an existing feature / command

cached plans and enable_partition_pruning

It seems that because enable_partition_pruning's value is only checked during planning, turning it off *after* a plan is created and cached does not work as expected. create table p (a int) partition by list (a); create table p1 partition of p for values in (1); create table p1 partition of p for

Re: partition tree inspection functions

Thanks for the review, Jesper. On 2018/07/18 23:35, Jesper Pedersen wrote: > On 06/28/2018 01:49 AM, Amit Langote wrote: >> OK, I've added an example below the table of functions added by the patch. >> >> Attached updated patch. >> > > You forgot to remove the te

Re: partition tree inspection functions

Hi Dilip, Sorry it took me a while to reply. On 2018/06/29 14:30, Dilip Kumar wrote: > On Tue, Jun 26, 2018 at 10:38 AM, Amit Langote wrote: >> As discussed a little while back [1] and also recently mentioned [2], here >> is a patch that adds a set of functions to insp

Re: documentation about explicit locking

On 2018/07/18 18:30, Peter Eisentraut wrote: > On 06.07.18 04:00, Amit Langote wrote: >> On 2018/07/05 23:02, Robert Haas wrote: >>> On Wed, Jul 4, 2018 at 3:09 AM, Amit Langote >>> wrote: >>>> I wonder why we mention on the following page that CREATE COLL

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

On 2018/07/21 0:17, David Rowley wrote: > On 20 July 2018 at 21:44, Amit Langote wrote: >> But I don't think the result of make_partition_pruneinfo itself has to be >> List of PartitionedRelPruneInfo nested under PartitionPruneInfo. I gather >> that each PartitionPruneInf

Re: ToDo: show size of partitioned table

Hi Pavel. On 2018/07/23 20:46, Pavel Stehule wrote: > Hi > > I am sending a prototype of patch. Now, it calculates size of partitioned > tables with recursive query. When any more simple method will be possible, > the size calculation will be changed. > > postgres=# \dt+ >

Re: How to make partitioning scale better for larger numbers of partitions

On 2018/07/17 12:14, Ashutosh Bapat wrote: > On Tue, Jul 17, 2018 at 8:31 AM, Kato, Sho wrote: >> On 2018/07/17 10:49, Amit Langote wrote: >>> Perhaps, Kato-san only intended to report that the time that planner spends >>> for a partitioned table with 1100 partition

Re: pointless check in RelationBuildPartitionDesc

On 2018/09/05 1:50, Alvaro Herrera wrote: > Proposed patch. Checking isnull in a elog(ERROR) is important, because > the column is not marked NOT NULL. This is not true for other columns > where we simply do Assert(!isnull). Looks good. Thanks for taking care of other sites as well. @@

Re: pointless check in RelationBuildPartitionDesc

On 2018/09/04 21:51, Alvaro Herrera wrote: > On 2018-Sep-04, Amit Langote wrote: > >> On 2018/09/04 13:08, Alvaro Herrera wrote: > >>> I think it'd be pointless noise. If we really want to protect against >>> that, I think we should promote the Assert f

Re: speeding up planning with partitions

On 2018/09/04 22:24, David Rowley wrote: > On 30 August 2018 at 00:06, Amit Langote > wrote: >> With various overheads gone thanks to 0001 and 0002, locking of all >> partitions via find_all_inheritos can be seen as the single largest >> bottleneck, which 0003 trie

Re: speeding up planning with partitions

On 2018/09/11 10:11, Peter Geoghegan wrote: > On Wed, Aug 29, 2018 at 5:06 AM, Amit Langote > wrote: >> It is more or less well known that the planner doesn't perform well with >> more than a few hundred partitions even when only a handful of partitions >> are ultimat

Re: speeding up planning with partitions

On 2018/08/30 10:09, Tsunakawa, Takayuki wrote: > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] >> I measured the gain in performance due to each patch on a modest virtual >> machine. Details of the measurement and results follow. > > Amazing! Thanks. >

Re: speeding up planning with partitions

On 2018/08/30 7:27, David Rowley wrote: > On 30 August 2018 at 00:06, Amit Langote > wrote: >> nparts master0001 0002 0003 >> == == >> 0 28562893 2862 2816 >> 8 5071115 1447 1872 >>

Re: speeding up planning with partitions

On 2018/08/29 21:06, Amit Langote wrote: > I measured the gain in performance due to each patch on a modest virtual > machine. Details of the measurement and results follow. > > UPDATE: > > nparts master0001 0002 0003 > == == > 0

Re: Server crashed with dense_rank on partition table.

On 2018/07/05 9:40, Andres Freund wrote: > On 2018-07-02 17:14:14 +0900, Amit Langote wrote: >> I studied this a bit and found a bug that's causing the crash. >> >> The above mentioned commit has this hunk: >> >> @@ -1309,6 +1311,9 @@ hypothetical_

documentation about explicit locking

Hi. I wonder why we mention on the following page that CREATE COLLATION requires SHARE ROW EXCLUSIVE lock https://www.postgresql.org/docs/devel/static/explicit-locking.html I know that's the lock taken on the pg_collation catalog, but do we need to mention locks taken by a DDL command on the

Re: why partition pruning doesn't work?

On 2018/06/19 2:05, Tom Lane wrote: > Amit Langote writes: >> [ 0001-Open-partitioned-tables-during-Append-initialization.patch ] > > I took a look at this. While I'm in agreement with the general idea of > holding open the partitioned relations' relcache entries throughout

Re: documentation fixes for partition pruning, round three

On 2018/07/06 6:55, David Rowley wrote: > On 6 July 2018 at 09:41, Alvaro Herrera wrote: >> On 2018-Jul-05, Peter Eisentraut wrote: >>> Committed. >> >> Thanks for handling this. >> >> Should we do this in REL_11_STABLE too? I vote yes. > > Sorry for now paying much attention to this, but I've

Re: Global shared meta cache

On 2018/07/05 23:00, Robert Haas wrote: > With respect to partitioning specifically, it seems like we might be > able to come up with some way of planning that doesn't need a full > relcache entry for every partition, particularly if there are no > partition-local objects (indexes, triggers,

Re: using expression syntax for partition bounds

Horiguchi-san, On 2018/07/06 14:26, Kyotaro HORIGUCHI wrote: > Hello. > > cf-bot compained on this but I wondered why it got so many > errors. At the first look I found a spare semicolon before a bare > then calause:p > >> -if (!IsA(value, Const)); >> +if (!IsA(value, Const)) >>

Re: documentation about explicit locking

On 2018/07/05 23:02, Robert Haas wrote: > On Wed, Jul 4, 2018 at 3:09 AM, Amit Langote > wrote: >> I wonder why we mention on the following page that CREATE COLLATION >> requires SHARE ROW EXCLUSIVE lock >> >> https://www.postgresql.org/docs/devel/static/explicit-lo

Re: no partition pruning when partitioning using array type

On 2018/07/07 0:13, Andrew Dunstan wrote: > > > On 05/08/2018 02:18 AM, Amit Langote wrote: >> On 2018/03/01 17:16, Amit Langote wrote: >>> Added this to CF (actually moved to the September one after first having >>> added it to the CF that is just getting

Re: no partition pruning when partitioning using array type

Thanks for taking a look. On 2018/07/07 9:19, Alvaro Herrera wrote: > On 2018-May-08, Amit Langote wrote: > >> I would like to revisit this as a bug fix for get_partition_operator() to >> be applied to both PG 10 and HEAD. In the former case, it fixes the bug >> that c

Re: no partition pruning when partitioning using array type

On 2018/07/11 3:18, Alvaro Herrera wrote: > On 2018-May-08, Amit Langote wrote: > >> In HEAD, since we already fixed that case in e5dcbb88a15d [1] which is a >> different piece of code anyway, the patch only serves to improve the >> deparse output emitted by ruleutils.c

Re: no partition pruning when partitioning using array type

On 2018/07/11 4:48, Alvaro Herrera wrote: > On 2018-Jul-10, Alvaro Herrera wrote: > >> alvherre=# explain update p set a = a || a where a = '{1}'; >> QUERY PLAN >> ── >> Update on p

Re: no partition pruning when partitioning using array type

On 2018/07/11 4:50, Alvaro Herrera wrote: > On 2018-Jul-10, Tom Lane wrote: > >> And what about those partition bound values? They are now illegal >> for the domain, so I would expect a dump/reload to fail, regardless >> of whether there are any values in the table. > > Hmm, true. There is a

Re: no partition pruning when partitioning using array type

On 2018/07/11 13:12, Alvaro Herrera wrote: > On 2018-Jul-11, Amit Langote wrote: > >> What's the solution here then? Prevent domains as partition key? > > Maybe if a domain is used in a partition key somewhere, prevent > constraints from being added? Maybe, but I guess

Re: How to make partitioning scale better for larger numbers of partitions

On 2018/07/13 14:49, Tsunakawa, Takayuki wrote: > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] >> For SELECT/UPDATE/DELETE, overhead of partitioning in the planning phase >> is pretty significant and gets worse as the number of partitions grows. >> I >> had

Re: How to make partitioning scale better for larger numbers of partitions

Kato-san, On 2018/07/13 11:58, Kato, Sho wrote: > Hi, > > I benchmarked on a RANGE partitioned table with 1.1k leaf partitions and no > sub-partitioned tables. Thanks for sharing the results. > But, statement latencies on a partitioned table is much slower than on a > non-partitioned table.

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

Thanks for the review. On 2018/07/12 22:01, Ashutosh Bapat wrote: > On Thu, Jul 12, 2018 at 11:10 AM, Amit Langote > wrote: >>> >>> I think your fix is correct. I slightly modified it along with updating >>> nearby comments and added regression tests. >>

Re: How to make partitioning scale better for larger numbers of partitions

On 2018/07/13 16:29, Kato, Sho wrote: > I also benchmark PG10. > Actually, SELECT latency on PG11beta2 + patch1 is faster than PG10. > > SELECT latency with 800 leaf partition > -- > PG10　5.62 ms > PG11 3.869 ms > > But, even PG11, SELECT statement takes

Re: Speeding up INSERTs and UPDATEs to partitioned tables

Hi David. On 2018/06/22 15:28, David Rowley wrote: > Hi, > > As part of my efforts to make partitioning scale better for larger > numbers of partitions, I've been looking at primarily INSERT VALUES > performance. Here the overheads are almost completely in the > executor. Planning of this type

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

Thanks Ashutosh for reporting and Dilip for the analysis and the patch. On 2018/07/11 21:39, Dilip Kumar wrote: > On Wed, Jul 11, 2018 at 5:36 PM, amul sul wrote: >> On Wed, Jul 11, 2018 at 5:10 PM Dilip Kumar wrote: > >>> >> I am not sure that I have understand the following comments >> 11 +

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

On 2018/07/12 14:32, Amit Langote wrote: > Thanks Ashutosh for reporting and Dilip for the analysis and the patch. > > On 2018/07/11 21:39, Dilip Kumar wrote: >> On Wed, Jul 11, 2018 at 5:36 PM, amul sul wrote: >>> On Wed, Jul 11, 2018 at 5:10 PM Dilip Kumar wrote: &

Re: Problem on pg_dump RANGE partition with expressions

Nagata-san, On 2018/07/12 16:59, Yugo Nagata wrote: > Hi, > > During looking into other thread[1], I found a problem on pg_dump of range > partition table using expressions. When we create a range partitioned table, > we cannot use a column more than　once in the partition key. > > postgres=#

Re: no partition pruning when partitioning using array type

On 2018/07/12 2:33, Alvaro Herrera wrote: > On 2018-Jul-11, Amit Langote wrote: > >> On 2018/07/11 13:12, Alvaro Herrera wrote: >>> On 2018-Jul-11, Amit Langote wrote: >>> >>>> What's the solution here then? Prevent domains as partition key? >>&g

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

Thanks Ashutosh. On 2018/07/10 22:50, Ashutosh Bapat wrote: > I didn't see any hackers thread linked to this CF entry. Hence sending this > mail through CF app. Hmm, yes. I hadn't posted the patch to -hackers. > The patch looks good to me. It applies cleanly, compiles cleanly and make >

Re: Incorrect comments in partition.c

On 2018/01/23 20:43, Etsuro Fujita wrote: > Here is a comment for get_qual_for_list in partition.c: > > * get_qual_for_list > * > * Returns an implicit-AND list of expressions to use as a list partition's > - * constraint, given the partition key and bound structures. > > I don't think the

Re: [HACKERS] path toward faster partition pruning

Thank you Horiguchi-san! On 2018/01/19 12:00, Kyotaro HORIGUCHI wrote: > At Thu, 18 Jan 2018 11:41:00 -0800, Andres Freund wrote: >> Hi Amit, >> >> It seems your mail system continually adds "[Sender Address Forgery]" >> prefixes to messages. E.g. this mail now has >>

Re: [HACKERS] Adding column_constraint description in ALTER TABLE synopsis

On 2018/01/23 8:57, Thomas Munro wrote: > On Tue, Jan 23, 2018 at 12:41 PM, Thomas Munro > wrote: >> On Mon, Jan 15, 2018 at 2:32 PM, Stephen Frost wrote: >>> If someone else would like to review it, that'd be great, otherwise I'll >>> probably

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/03/01 1:03, Robert Haas wrote: > On Tue, Feb 27, 2018 at 7:46 PM, 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

Re: [HACKERS] path toward faster partition pruning

On 2018/02/28 19:14, Ashutosh Bapat wrote: > On Wed, Feb 28, 2018 at 6:42 AM, Amit Langote wrote: >> BTW, should there be a relevant test in partition_join.sql? If yes, >> attached a patch (partitionwise-join-collation-test-1.patch) to add one. > > A partition-wise join

Re: no partition pruning when partitioning using array type

On 2018/02/02 0:20, Robert Haas wrote: > On Thu, Feb 1, 2018 at 4:42 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >>> I hope someone else chimes in as well. :) >> >> Bug #15042 [1] seems to be caused by this same problem. There, a >

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

On 2018/03/14 17:16, Amit Langote wrote: > On 2018/03/10 13:40, Tom Lane wrote: >> I wrote: >>> I think it'd make more sense to see about incorporating that idea in >>> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause. >> >> After f

Re: inserts into partitioned table may cause crash

Fujita-san, Thanks for the updates and sorry I couldn't reply sooner. On 2018/03/06 21:26, Etsuro Fujita wrote: > One thing I notice while working on this is this in ExecInsert/CopyFrom, > which I moved to ExecPrepareTupleRouting as-is for the former: > > /* > * If we're capturing

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

On 2018/03/10 13:40, Tom Lane wrote: > I wrote: >> I think it'd make more sense to see about incorporating that idea in >> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause. > > After further thought, it seems like the place to deal with this is > really

Re: inserts into partitioned table may cause crash

On 2018/03/14 17:35, Etsuro Fujita wrote: > (2018/03/14 17:25), Etsuro Fujita wrote: >> (2018/03/14 14:54), Amit Langote wrote: >>> Sorry that this may be nitpicking that I should've brought up before, but >>> doesn't ExecPrepareTupleRouting do all the work that's nee

Re: [HACKERS] path toward faster partition pruning

On 2018/03/14 8:26, Alvaro Herrera wrote: > By the way, I checked whether patch 0002 (additional tests) had an > effect on coverage, and couldn't detect any changes in terms of > lines/functions. Were you able to find any bugs in your code thanks to > the new tests that would not have been

Re: [HACKERS] path toward faster partition pruning

On 2018/03/14 20:50, David Rowley wrote: > On 14 March 2018 at 00:37, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Attached is a significantly revised version of the patch, although I admit >> it could still use some work with regard to comments and other cleanup. &

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

On 2018/03/06 18:46, Emre Hasegeli wrote: >> Patch teaches it to ignore nulls when it's known that the operator being >> used is strict. It is harmless and has the benefit that constraint >> exclusion gives an answer that is consistent with what actually running >> such a qual against a table's

Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/03/05 17:38, Amit Langote wrote: > I'll > post an update in a couple of days to report on how that works out. I'm still working on this and getting most of the tests to pass with the new code, but not all of them yet. Thanks, Amit

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

On 2018/04/03 14:45, Kyotaro HORIGUCHI wrote: > Hello. > > At Mon, 2 Apr 2018 16:11:12 -0300, Alvaro Herrera > wrote: >> Why do we need AccessExclusiveLock on all children of a relation that we >> want to scan to search for rows not satisfying the constraint? I think

Re: [HACKERS] Runtime Partition Pruning

Hi David. On 2018/03/31 22:52, David Rowley wrote: > The attached patchset is based on Amit's v45 faster partition pruning [1]. > > I've made a few changes since the v14 version. Since Amit's v45 patch > now creates the partition pruning details in a data structure that can > be copied from the

Re: [HACKERS] path toward faster partition pruning

On Sat, Apr 7, 2018 at 10:31 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 7 April 2018 at 12:43, David Rowley <david.row...@2ndquadrant.com> wrote: >> On 7 April 2018 at 12:35, Amit Langote <amitlangot...@gmail.com> wrote: >>> So this same failur

Re: [HACKERS] path toward faster partition pruning

Thank you Alvaro for rest of the cleanup and committing. On Sat, Apr 7, 2018 at 5:28 AM, Alvaro Herrera wrote: > So I pushed this 25 minutes ago, and already there's a couple of > buildfarm members complaining: >

Re: [HACKERS] Runtime Partition Pruning

On Sat, Apr 7, 2018 at 11:26 AM, David Rowley wrote: > Everything else looks fine from my point of view. Me too, although I still think having struct names PartitionPruning and PartitionRelPruning is going to be a bit confusing. We should think about naming the

Re: [HACKERS] Runtime Partition Pruning

On Sat, Apr 7, 2018 at 1:58 PM, David Rowley wrote: > Probably if we need to explain more there about how pruning works then > it should be a fixup patch to 9fdb675fc, no? Yes, I just replied and working on a patch. Thanks, Amit

Re: [HACKERS] Runtime Partition Pruning

On Sat, Apr 7, 2018 at 1:31 PM, Andres Freund <and...@anarazel.de> wrote: > On 2018-04-07 13:26:51 +0900, Amit Langote wrote: >> On Sat, Apr 7, 2018 at 11:26 AM, David Rowley >> <david.row...@2ndquadrant.com> wrote: >> > Everything else looks fine from my poi

Re: [HACKERS] path toward faster partition pruning

On Sat, Apr 7, 2018 at 1:09 PM, Andres Freund wrote: > Hi, > > On 2018-04-07 15:49:54 +1200, David Rowley wrote: >> Right, I suggest we wait and see if all members go green again as a >> result of 40e42e1024c, and if they're happy then we could maybe leave >> it as is with the

Re: [HACKERS] Runtime Partition Pruning

On Sat, Apr 7, 2018 at 1:58 PM, Amit Langote <amitlangot...@gmail.com> wrote: > On Sat, Apr 7, 2018 at 1:31 PM, Andres Freund <and...@anarazel.de> wrote: >> I've not followed this thread/feature at all, but I don't find the >> comments atop partprune.c even remotely

Re: [HACKERS] path toward faster partition pruning

On Sat, Apr 7, 2018 at 1:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <amitlangot...@gmail.com> writes: >> Given that the difference only appeared on animals that David pointed >> out have big-endian architecture, it seems we'd only need two output >>

Re: [HACKERS] Runtime Partition Pruning

Hi David. On 2018/04/05 22:41, David Rowley wrote: >> * make_partition_pruneinfo has a parameter resultRelations that's not used >> anywhere > > It gets used in 0005. > > I guess I could only add it in 0005, but make_partition_pruneinfo is > only used in 0003, so you could say the same about

Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/04/06 7:35, Alvaro Herrera wrote: > I seems pretty clear that putting get_matching_partitions() in > catalog/partition.c is totally the wrong thing; it belongs wholly in > partprune. I think the reason you put it there is that it requires > access to a lot of internals that are static

Re: [HACKERS] Runtime Partition Pruning

Hi David, On 2018/04/06 12:27, David Rowley wrote: > (sending my reply in parts for concurrency) > > On 6 April 2018 at 14:39, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> I think we can save some space here by not having the pointers stored >> here. Ins

Re: Partitioned tables and covering indexes

On 2018/04/10 16:07, Jaime Casanova wrote: > Hi, > > Trying covering indexes on partitioned tables i get this error > """ > postgres=# create index on t1_part (i) include (t); > ERROR: cache lookup failed for opclass 0 > """ > > To reproduce: > > create table t1_part (i int, t text) partition

Re: [HACKERS] path toward faster partition pruning

On 2018/04/10 13:27, Ashutosh Bapat wrote: > On Mon, Apr 9, 2018 at 8:56 PM, Robert Haas wrote: >> On Fri, Apr 6, 2018 at 11:41 PM, Tom Lane wrote: >>> David Rowley writes: Sounds like you're saying that if we have

crash with sql language partition support function

Hi. I noticed that RelationBuildPartitionKey() is not doing the right thing with respect to which context it passes to fmgr.c to set a the (cached) partition support function's FmgrInfo's fn_mcxt. I noticed a crash while trying to change partition pruning tests to use manually created hash

Re: crash with sql language partition support function

I have added this in the Older Bugs section of open items page. https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Older_Bugs Thanks, Amit

Re: Boolean partitions syntax

Horiguchi-san, Thanks for working on this. On 2018/04/11 13:20, Kyotaro HORIGUCHI wrote: > At Wed, 11 Apr 2018 11:27:17 +0900, Amit Langote wrote: >> On 2018/04/11 10:44, Tom Lane wrote: >>> Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: >>>

Re: Boolean partitions syntax

On 2018/04/11 13:39, David Rowley wrote: > On 11 April 2018 at 05:22, Tom Lane wrote: >> David Rowley writes: >>> On 11 April 2018 at 03:34, Tom Lane wrote: Well, that just begs the question: why do these expressions

Re: [HACKERS] path toward faster partition pruning

int8) RETURNS int8 AS >> +$$SELECT length(coalesce($1))::int8$$ LANGUAGE sql IMMUTABLE STRICT; >> >> >> Why coalesce here? Maybe I've not thought of something, but coalesce >> only seems useful to me if there's > 1 argument. Plus the function is >> strict, so not

Re: [HACKERS] path toward faster partition pruning

Thanks for the review. On 2018/04/10 21:02, David Rowley wrote: > On 10 April 2018 at 20:56, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> On 2018/04/10 13:27, Ashutosh Bapat wrote: >>> On Mon, Apr 9, 2018 at 8:56 PM, Robert Haas <robertmh...@gmail.com>

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

Fuiita-san, On 2018/04/05 15:56, Etsuro Fujita wrote: > (2018/04/05 15:37), Amit Langote wrote: >> I noticed that the 2nd patch (foreign-routing-fdwapi-5.patch) fails to >> apply to copy.c: > > I forgot to mention this: the second patch is created on top of the first

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

On 2018/04/05 16:31, Amit Langote wrote: > Fuiita-san, Oops, sorry about misspelling your name here, Fujita-san. - Amit

Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/04/05 0:45, Jesper Pedersen wrote: > Hi, > > On 04/04/2018 09:29 AM, David Rowley wrote: >> Thanks for updating. I've made a pass over v49 and I didn't find very >> much wrong with it. >> >> The only real bug I found was a missing IsA(rinfo->clause, Const) in >> the pseudoconstant

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

Fujita-san, On 2018/04/05 15:02, Etsuro Fujita wrote: > (2018/04/04 19:31), Etsuro Fujita wrote: >> Attached is an updated version of the patch set: >> * As before, patch foreign-routing-fdwapi-4.patch is created on top of >> patch postgres-fdw-refactoring-4.patch and the bug-fix patch [1]. > >

Re: [HACKERS] path toward faster partition pruning

Hi David. Thanks for the review. On 2018/04/11 17:59, David Rowley wrote: > On 11 April 2018 at 18:04, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Updated patch attached. > > Thanks for the updated patch. > > The only thing I'm not sure about

Re: partitioning code reorganization

Hi. Thanks for taking care of few things I left like those PartitionKey accessors in rel.h. On Sat, Apr 14, 2018 at 8:51 PM, Alvaro Herrera wrote: > Here's a final version. > > The one thing I don't like about this is having put > PartitionRangeDatumKind in partdefs.h,

Re: partitioning code reorganization

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 > accessors in rel.h. Forgot to mention -- there are some files that still include catalog/partition.h but no longer need

Re: ON CONFLICT DO UPDATE for partitioned tables

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 ... but >> we already have it in the TupleConversionMa

Re: [sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step

On 2018/04/09 22:59, Alvaro Herrera wrote: > Hello, > > Amit Langote wrote: > >> I have reproduced this and found that the problem is that >> perform_pruning_combine_step forgets to *copy* the bitmapset of the first >> step in the handling of an COMBINE_INTERSECT

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

Thanks for the comment. On 2018/04/09 23:22, Tom Lane wrote: > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >> I noticed that the newly added pruning does not work if the partition key >> is of one of the types that have a corresponding pseudo-type. > > While

Re: [sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step

On 2018/04/10 13:55, Michael Paquier wrote: > On Mon, Apr 09, 2018 at 10:59:48AM -0300, Alvaro Herrera wrote: >> Amit Langote wrote: >>> I have reproduced this and found that the problem is that >>> perform_pruning_combine_step forgets to *copy* the bitmapset of the fir

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

Hi. I noticed that the newly added pruning does not work if the partition key is of one of the types that have a corresponding pseudo-type. -- array type list partition key create table arrpart (a int[]) partition by list (a); create table arrpart1 partition of arrpart for values in ('{1}');

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

On 2018/04/09 19:14, Amit Langote wrote: > Hi. > > I noticed that the newly added pruning does not work if the partition key > is of one of the types that have a corresponding pseudo-type. > > -- array type list partition key > create table arrpart (a int[]) partition by lis

Re: [HACKERS] path toward faster partition pruning

Hi David. On 2018/04/09 12:48, David Rowley wrote: > While looking at the docs in [1], I saw that we still mention: > > 4. Ensure that the constraint_exclusion configuration parameter is not > disabled in postgresql.conf. If it is, queries will not be optimized > as desired. > > This is no

Re: [sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step

On 2018/04/09 17:50, Amit Langote wrote: > Attached fixes that. I see that Michael Paquier has added this to the > open items list. Thanks, Michael. > > https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Open_Issues Oops, it was Tom who added that. Thank you! Regards, Amit

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/04/06 5:00, Andres Freund wrote: > On 2018-04-05 11:31:48 +0530, Pavan Deolasee wrote: >>> + /* >>> +* If there are not WHEN MATCHED actions, we are done. >>> +*/ >>> + if (mergeMatchedActionStates == NIL) >>> + return true; >>> >>> Maybe I'm confused, but why is

Re: [sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step

Hi Andreas. On 2018/04/08 3:33, Andreas Seltenreich wrote: > Hi, > > testing with master at 039eb6e92f yielded another query triggering an > assertion. Thanks for the report. > Backtrace and query against the regression database below. > #0 __GI_raise (sig=sig@entry=6) at

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

On Sun, Apr 8, 2018 at 5:37 AM, Andres Freund wrote: > On 2018-04-06 19:25:20 -0400, Robert Haas wrote: >> On Thu, Apr 5, 2018 at 6:21 AM, Etsuro Fujita >> wrote: >> > Attached is an updated version of the patch set plus the patch in [1]. >> >

Re: [HACKERS] Runtime Partition Pruning

On 2018/04/13 1:57, Robert Haas wrote: >> It might be possible to do something better in each module by keeping >> an array indexed by RTI which have each entry NULL initially then on >> first relation_open set the element in the array to that pointer. > > I'm not sure that makes a lot of sense

Re: [HACKERS] Runtime Partition Pruning

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 partitioned_rels list in ExecLockNonleafAppendTables That may have soun

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