Re: Partitioning with temp tables is broken

On 2018/06/14 23:42, Tom Lane wrote: > Ashutosh Bapat writes: >> If I am reading Tom's reply upthread correctly, we should not allow >> creating a temporary partitioned table as well as temporary partitions >> altogether. > > I think that if possible, we should still allow a partitioned table >

Re: Partitioning with temp tables is broken

On 2018/06/14 22:11, Ashutosh Bapat wrote: > On Thu, Jun 14, 2018 at 9:42 AM, Amit Langote >> I'm attaching a patch here to forbid adding a temporary table as partition >> of permanent table. I didn't however touch the feature that allows *all* >> members in a partition

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

On 2018/06/15 20:41, David Rowley wrote: > On 15 June 2018 at 20:37, Amit Langote wrote: >> select * from partitioned_table_a >> union all >> select * from partitioned_table_b >> >> The only thing that changes with the patch is that >> ExecLockNonLeafApp

Re: Partitioning with temp tables is broken

Hi. On 2018/06/17 22:11, Michael Paquier wrote: > On Thu, Jun 14, 2018 at 10:38:14PM -0400, Tom Lane wrote: >> David Rowley writes: >>> On 15 June 2018 at 02:42, Tom Lane wrote: I think that if possible, we should still allow a partitioned table in which all the rels are temp tables

Re: why partition pruning doesn't work?

On 2018/06/13 23:39, Tom Lane wrote: > Robert Haas writes: >> Seems reasonable. Really, I think we should look for a way to hang >> onto the relation at the point where it's originally opened and locked >> instead of reopening it here. But that's probably more invasive than >> we can really

Re: Needless additional partition check in INSERT?

On 2018/06/09 3:41, Alvaro Herrera wrote: > BTW, while working on this, I was a bit disturbed by the > execReplication.c changes (namely: if the partitioning is not identical > on both sides, things are likely to blow up pretty badly), but that's a > separate topic. Hmm, yes. If the partition of

Re: Getting "ERROR: did not find all requested child rels in append_rel_list" when enable_partition_pruning is on

On 2018/06/15 16:32, Rajkumar Raghuwanshi wrote: > Hi, > > I am getting "ERROR: did not find all requested child rels in > append_rel_list" when enable_partition_pruning is on for below test case. > > CREATE TABLE test(c1 int, c2 int) PARTITION BY RANGE(c1); > CREATE TABLE test_p1 PARTITION OF

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

On 2018/06/11 16:49, David Rowley wrote: > On 11 June 2018 at 12:19, Tom Lane wrote: >> David Rowley writes: >>> On 10 June 2018 at 04:48, Tom Lane wrote: So, IIUC, the issue is that for partitioning cases Append expects *all* its children to be partitions of the *same* partitioned

Re: Partitioning with temp tables is broken

On 2018/06/13 21:06, David Rowley wrote: > There's also something pretty weird around the removal of the temp > relation from the partition bound. I've had cases where the session > that attached the temp table is long gone, but \d+ shows the table is > still there and I can't attach another

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/14 22:45, Ashutosh Bapat wrote: > On Thu, Jun 14, 2018 at 6:49 PM, Robert Haas wrote: >> It sounds like you want to try to hide from users the fact that they >> can create triggers on the individual partitions. > > No. I never said that in my mails (see [1], [2]) I object to the >

Re: why partition pruning doesn't work?

On 2018/06/14 23:40, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 14, 2018 at 7:23 AM, David Rowley >> wrote: >>> However, I only spent about 10 mins looking into this, there may be >>> some giant holes in the idea. It would need much more research. > >> It kind of flies in the face of

Re: why partition pruning doesn't work?

On 2018/06/14 20:23, David Rowley wrote: > On 14 June 2018 at 19:17, Amit Langote wrote: >> I had sent a patch to try to get rid of the open(NoLock) there a couple of >> months ago [1]. The idea was to both lock and open the relation in >> ExecNonLeafAppendTables, which

Re: New committers announced at PGCon 2018

On Fri, Jun 1, 2018 at 5:05 PM, Tom Lane wrote: > The core team is pleased to announce the appointment of seven > new Postgres committers: > > Etsuro Fujita > Peter Geoghegan > Amit Kapila > Alexander Korotkov > Thomas Munro > Michael Paquier > Tomas Vondra > > Congratulations to all!

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/05 1:25, Alvaro Herrera wrote: > In the meantime, my inclination is to fix the documentation to point out > that AFTER triggers are allowed but BEFORE triggers are not. Wasn't that already fixed by bcded2609ade6? We don't say anything about AFTER triggers per se, but the following

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/05 16:41, Ashutosh Bapat wrote: > On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote > wrote: >> On 2018/06/05 1:25, Alvaro Herrera wrote: >>> In the meantime, my inclination is to fix the documentation to point out >>> that AFTER triggers a

Re: why partition pruning doesn't work?

Hi Dmitry, Thanks for creating the patch. I looked at it and have some comments. On 2018/06/04 22:30, Dmitry Dolgov wrote: >> On 3 June 2018 at 19:11, Tom Lane wrote: >> Dmitry Dolgov <9erthali...@gmail.com> writes: >>> Just to clarify for myself, for evaluating any stable function here would

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/06 2:08, Alvaro Herrera wrote: > On 2018-Jun-05, Amit Langote wrote: > >> On 2018/06/05 16:41, Ashutosh Bapat wrote: >>> On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote >>> wrote: >>>> On 2018/06/05 1:25, Alvaro Herrera wrote: >&

Re: why partition pruning doesn't work?

On 2018/06/06 14:10, David Rowley wrote: > I then decided that > I didn't like the way we need to check which params are in the Expr > each time we call partkey_datum_from_expr. It seems better to prepare > this in advance when building the pruning steps. I started work on > that, but soon

Re: Needless additional partition check in INSERT?

On 2018/06/07 12:57, Alvaro Herrera wrote: > On 2018-Jun-07, David Rowley wrote: >> I'm personally not really for or against having the function. I agree >> that it's slightly weird, but anyway, here's the patch. I'll leave it >> up to you to which one you prefer, v3 or v4. > > Hm I was thinking

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/06 20:51, Ashutosh Bapat wrote: > The existing wording suggests that the user > creates the triggers on the partitioned table, and that will be > supported always, which can lead to problems. Do you mean the following wording "BEFORE ROW triggers, if necessary, must be defined on

Re: why partition pruning doesn't work?

On 2018/06/06 18:52, David Rowley wrote: > On 6 June 2018 at 18:05, Amit Langote wrote: >> On 2018/06/06 14:10, David Rowley wrote: >>> I then decided that >>> I didn't like the way we need to check which params are in the Expr >>> each time we call part

Fix obsolete comment

Hi. A comment in ExecUpdate refers to an argument of ExecConstraints that no longer exists. Attached fixes that, but I'm about over a year too late [1] in sending this patch. Thanks, Amit [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c0a8ae7be392 diff --git

Re: Fix obsolete comment

On 2018/06/07 16:03, Heikki Linnakangas wrote: > On 07/06/18 09:43, Amit Langote wrote: >> A comment in ExecUpdate refers to an argument of ExecConstraints that no >> longer exists.  Attached fixes that, but I'm about over a year too late >> [1] in sending this patch. > &g

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/07 14:17, Ashutosh Bapat wrote: >> that is, users can find out about that feature by themselves by >> trying it out? > > I didn't understand that part. > > Probably we just say that BEFORE ROW triggers are not supported on a > partitioned table. It's good enough not to suggest it

Re: Needless additional partition check in INSERT?

On 2018/06/07 13:10, David Rowley wrote: > On 7 June 2018 at 16:05, Amit Langote wrote: >> Or we could just not have a separate function and put the logic that >> determines whether or not to check the partition constraint right before >> the following piece of co

Re: Server crashed with dense_rank on partition table.

On 2018/06/13 16:35, Amit Langote wrote: > Fwiw, I see that the crash can also occur even when using a > non-partitioned table in the query, as shown in the following example > which reuses Rajkumar's test data and query: > > create table foo (a int, b int, c text); > postgres

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/07/02 14:46, Ashutosh Bapat wrote: > This constraint was added to the partitioned table and inherited from > there. If user wants to drop that constraint for some reason, this > error message doesn't help. The error message tells why he can't drop > it, but doesn't tell, directly or

Re: using expression syntax for partition bounds

Horiguchi-san, Thanks a lot for the review and sorry it took me a while to reply. Thought I'd refresh the patch as it's in the July CF. On 2018/04/24 18:08, Kyotaro HORIGUCHI wrote: > Thanks. I have almost missed this. > > At Mon, 23 Apr 2018 11:44:14 +0900, Amit Langote wrote: >>

partition tree inspection functions

Hi. As discussed a little while back [1] and also recently mentioned [2], here is a patch that adds a set of functions to inspect the details of a partition tree. There are three functions: pg_partition_parent(regclass) returns regclass pg_partition_root_parent(regclass) returns regclass

Re: partition tree inspection functions

On 2018/06/26 14:08, Amit Langote wrote: > Hi. > > As discussed a little while back [1] and also recently mentioned [2], here > is a patch that adds a set of functions to inspect the details of a > partition tree. There are three functions: > > pg_partition_parent(regcl

Re: partition tree inspection functions

On 2018/06/26 16:54, Jeevan Ladhe wrote: > Hi Amit, > > On Tue, Jun 26, 2018 at 1:07 PM, Amit Langote > wrote: > >> On 2018/06/26 14:08, Amit Langote wrote: >>> Hi. >>> >>> As discussed a little while back [1] and also recently mentioned [2], >

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hi Ashutosh, On 2018/05/14 20:14, Ashutosh Bapat wrote: > 0001-Hash-partition-bound-equality-refactoring.patch > 0002-Targetlist-of-a-child-join-is-produced-by-translatin.patch > 0003-Partition-wise-join-for-1-1-1-0-0-1-partition-matchi.patch >

Re: bug with expression index on partition

On 2018/06/23 6:51, Alvaro Herrera wrote: > On 2018-Jun-21, Amit Langote wrote: > >> explain (costs off) select p from p order by p; >> QUERY PLAN >> --- >> Merge Append >>Sort Key: ((p1.*)::p) >&

Re: Generating partitioning tuple conversion maps faster

On 2018/06/25 14:12, amul sul wrote: > On Mon, Jun 25, 2018 at 10:30 AM David Rowley > wrote: >> > [...] >> Given the small size of this patch. I think it's a good candidate for >> the July 'fest. >> > > Just a different thought, how about having flag array something like > needed_tuple_conv? >

Re: bug with expression index on partition

On 2018/06/23 5:54, Alvaro Herrera wrote: > On 2018-Jun-21, Amit Langote wrote: > >> On 2018/06/21 15:35, Amit Langote wrote: >>> So, CompareIndexInfo and generateClonedIndexStmt are both doing the right >>> thing, but DefineIndex is not. Attached is

Re: postgresql_fdw doesn't handle defaults correctly

Hi. On 2018/06/24 2:23, Pavel Stehule wrote: > Hi > > I have a table boo > > create table boo(id serial primary key, inserted date default current_date, > v varchar); > > I imported this table via simple > > IMPORT FOREIGN SCHEMA public FROM SERVER foreign_server INTO public; It seems you

Re: partition -> partitioned

On 2018/06/21 0:45, Alvaro Herrera wrote: > On 2018-Jun-19, Amit Langote wrote: > >> Noticed that the relevant code changed, so I rebased the patch. Also, >> made a minor update to a nearby comment. > > Pushed, thanks. I made a couple of comments one or two wo

Re: ToDo: show size of partitioned table

On 2018/06/20 16:21, Pavel Stehule wrote: > 2018-06-20 7:44 GMT+02:00 Amit Langote : > >> On 2018/06/02 0:15, Ashutosh Bapat wrote: >>> I think we should at least display "Type" as "partitioned table" for a >>> partitioned table, so that it's eas

Re: ToDo: show size of partitioned table

On 2018/06/20 16:50, Pavel Stehule wrote: > 2018-06-20 9:44 GMT+02:00 Amit Langote : >> Do you mean \dt continues to show size 0 for partitioned tables, but with >> the new option (\dtP+) shows the actual size by aggregating across >> partitions? +1 to such a feature,

Re: Partitioning with temp tables is broken

On 2018/06/20 10:54, Michael Paquier wrote: > On Tue, Jun 19, 2018 at 04:26:56PM +0530, Ashutosh Bapat wrote: >> On Tue, Jun 19, 2018 at 4:22 PM, Michael Paquier wrote: >>> I was under the impression that this was implied in the precious >>> phrasing but you guys visibly don't match with my

Re: ToDo: show size of partitioned table

On 2018/06/02 0:15, Ashutosh Bapat wrote: > I think we should at least display "Type" as "partitioned table" for a > partitioned table, so that it's easy to understand why the size is 0; > partitioned tables do not hold any data by themselves. There was a long discussion last year (during PG 10

Re: bug with expression index on partition

On 2018/06/21 15:35, Amit Langote wrote: > So, CompareIndexInfo and generateClonedIndexStmt are both doing the right > thing, but DefineIndex is not. Attached is a patch to fix DefineIndex so > that it converts indexParams before recursing to create the index on a > partition

Re: partitioning - changing a slot's descriptor is expensive

On 2018/06/27 14:55, Andres Freund wrote: > On 2018-06-27 14:46:26 +0900, Amit Langote wrote: >> There is however similar code that runs in non-error paths, such as in >> ExecPrepareTupleRouting(), that is executed *if* the leaf partition and >> the root parent have differ

Re: partitioning - changing a slot's descriptor is expensive

Hi Andres, On 2018/06/27 14:09, Andres Freund wrote: > Hi, > > (sorry if I CCed the wrong folks, the code has changed a fair bit) > > I noticed that several places in the partitioning code look like: > > /* > * If the tuple has been routed, it's been converted to the > *

Re: postgresql_fdw doesn't handle defaults correctly

On 2018/06/27 2:47, Pavel Stehule wrote: > 2018-06-25 4:30 GMT+02:00 Amit Langote : >> It seems you missed using OPTIONS (import_default 'true') here. >> >> create schema foo; >> create table foo.foo (a serial primary key, b date default current_date >> not n

Re: postgresql_fdw doesn't handle defaults correctly

On 2018/06/27 15:33, Pavel Stehule wrote: >>> Unfortunately, when I use identity column >>> >>> create table foo(a int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, b >> date >>> default current_date, c int); >>> >>> then import doesn't fail, but still it doesn't work >> >> It seems that, unlike

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On 2018/06/26 18:02, Ashutosh Bapat wrote: > On Tue, Jun 26, 2018 at 2:27 PM, Amit Langote > wrote: >> Hi Ashutosh, >> >> On 2018/05/14 20:14, Ashutosh Bapat wrote: >>> 0001-Hash-partition-bound-equality-refactoring.patch >>> 0002-Targetlist-of-a-

Re: postgresql_fdw doesn't handle defaults correctly

On 2018/06/27 15:59, Pavel Stehule wrote: > 2018-06-27 8:45 GMT+02:00 Amit Langote : >> On 2018/06/27 15:33, Pavel Stehule wrote: >>> I don't understand, why is necessary to replace missing values by NULLs? >>> >>> I didn't expect so insert into foo(c) v

Re: Performance regression with PostgreSQL 11 and partitioning

On 2018/06/26 23:43, Alvaro Herrera wrote: > On 2018-Jun-25, Tom Lane wrote: > >> Alvaro Herrera writes: >>> On 2018-Jun-18, David Rowley wrote: I've attached a patch which cleans up my earlier version and moves the setup of the append_rel_array into its own function instead of

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/07/03 11:49, Robert Haas wrote: > On Mon, Jul 2, 2018 at 1:46 AM, Ashutosh Bapat > wrote: >> This constraint was added to the partitioned table and inherited from >> there. If user wants to drop that constraint for some reason, this >> error message doesn't help. The error message tells

Re: pgsql: Clarify use of temporary tables within partition trees

Just realized something... On 2018/07/03 15:29, Amit Langote wrote: > Sorry for jumping in late here. I have a comment on the patch. > > + /* if there are no partitions then treat this as non-inheritance case. > */ > + if (partdesc->nparts == 0) > + { > +

Re: pgsql: Clarify use of temporary tables within partition trees

On 2018/07/03 15:16, David Rowley wrote: > On 3 July 2018 at 18:11, Michael Paquier wrote: >> On Tue, Jul 03, 2018 at 06:00:46PM +1200, David Rowley wrote: >>> I think it should be backpatched to v11 and v10. Your original commit >>> went there too. I don't see any reason to do any different here

Re: pgsql: Clarify use of temporary tables within partition trees

On 2018/07/03 17:31, Amit Langote wrote: > On 2018/07/03 16:05, Michael Paquier wrote: >> On Tue, Jul 03, 2018 at 03:49:44PM +0900, Amit Langote wrote: >>> I forgot that expand_partitioned_rtentry() will recursively call itself if >>> a partition is itself a parti

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/05/02 14:17, Ashutosh Bapat wrote: > On Tue, May 1, 2018 at 5:20 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: >> On 4/26/18 05:03, Amit Langote wrote: >>> On 2018/04/26 13:01, David Rowley wrote: >>>> The attached small patch remo

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/05/01 20:50, Peter Eisentraut wrote: > On 4/26/18 05:03, Amit Langote wrote: >> On 2018/04/26 13:01, David Rowley wrote: >>> The attached small patch removes the mention that partitioned tables >>> cannot have foreign keys defined on them. >>> >&g

Re: Oddity in tuple routing for foreign partitions

On 2018/05/02 6:09, Andres Freund wrote: > On 2018-05-01 13:41:32 -0400, Robert Haas wrote: >> On Thu, Apr 26, 2018 at 9:23 PM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>>>> Thanks for reviewing! >>>> >>>> I'm

Re: [SPAM] Re: Local partitioned indexes and pageinspect

Hi. On 2018/05/02 11:05, Michael Paquier wrote: > On Tue, May 01, 2018 at 12:30:44PM -0400, Robert Haas wrote: >> However, backing up a minute, I don't think "relation \"%s\" is not a >> btree index" is such a terrible message. These modules are intended >> to be intended by people who Know What

Re: Local partitioned indexes and pageinspect

On 2018/05/02 13:38, Amit Langote wrote: > --- a/contrib/amcheck/expected/check_btree.out > +++ b/contrib/amcheck/expected/check_btree.out > > +-- verify partitioned tables are rejected (error) > +SELECT bt_index_check('bttest_partitioned'); > +ERROR: "bttest_parti

Re: stats_ext test fails with -DCATCACHE_FORCE_RELEASE

On 2018/05/02 0:33, Tom Lane wrote: > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >> While playing around with a -DCATCACHE_FORCE_RELEASE build, I noticed that >> stats_ext test failed with errors for multiple statements that looked like >> this: >>

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

Hi David. On 2018/05/02 8:18, David Rowley wrote: > On 1 May 2018 at 21:44, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> About the patch in general, it seems like the newly added documentation >> talks about "Partition Pruning" as something that *re

Re: Oddity in tuple routing for foreign partitions

On 2018/04/26 15:27, Etsuro Fujita wrote: > (2018/04/26 12:43), Etsuro Fujita wrote: >> (2018/04/25 17:29), Amit Langote wrote: >>> On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote: >>>> At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote: >>>>> After t

Re: Oddity in tuple routing for foreign partitions

On 2018/04/26 12:43, Etsuro Fujita wrote: > (2018/04/25 17:29), Amit Langote wrote: >> Hmm, I missed that we do need information from a proper RTE as well.  So, >> I suppose we should be doing this instead of creating the RTE for foreign >> partition from scratch. >> &g

Re: Oddity in tuple routing for foreign partitions

On 2018/04/26 2:59, Robert Haas wrote: > On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> I tried to do that. So, attached are two patches. >> >> 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to >&

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/04/26 13:01, David Rowley wrote: > The attached small patch removes the mention that partitioned tables > cannot have foreign keys defined on them. > > This has been supported since 3de241db I noticed also that the item regarding row triggers might be obsolete as of 86f575948c7, thanks

Re: description of root_tuple_slot missing

On 2018/04/27 3:54, Bruce Momjian wrote: > On Mon, Apr 23, 2018 at 02:50:10PM +0900, Amit Langote wrote: >> 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

Re: FOR EACH ROW triggers on partitioned tables

On 2018/04/30 18:38, Ashutosh Bapat wrote: > On Fri, Mar 23, 2018 at 7:19 PM, Alvaro Herrera > wrote: >> Pushed. Thanks for all the review. >> > > https://www.postgresql.org/docs/devel/static/ddl-partitioning.html > > section 5.10.2.3 still says > "Row triggers, if

Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

On 2018/04/29 1:00, Justin Pryzby wrote: > On Tue, Jul 18, 2017 at 07:26:30PM -0400, Tom Lane wrote: >>> It's probably a bit late in the v10 cycle to be taking any risks in >>> this area, but I'd vote for ripping out RememberToFreeTupleDescAtEOX >>> as soon as the v11 cycle opens, unless someone

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

On 2018/04/26 16:29, David Rowley wrote: > On 25 April 2018 at 09:59, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: >> Amit Langote wrote: >>> Although the config.sgml coverage of the new capabilities seems pretty >>> good, some may find their being men

Re: minor fix for acquire_inherited_sample_rows

On 2018/04/27 22:42, Ashutosh Bapat wrote: > On Thu, Apr 26, 2018 at 7:08 PM, Amit Langote <amitlangot...@gmail.com> wrote: >> On Thu, Apr 26, 2018 at 9:54 PM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>> On Thu, Apr 26, 2018 at 1:08 AM, Rober

move PartitionDispatchData definition to execPartition.c

Hi. I think we may have simply forgotten to do $subject in the following commit. commit da6f3e45ddb68ab3161076e120e7c32cfd46d1db Author: Alvaro Herrera Date: Sat Apr 14 21:12:14 2018 -0300 Reorganize partitioning code Attached a patch. Thanks, Amit From

Re: [HACKERS] path toward faster partition pruning

David On 2017/12/21 21:04, David Rowley wrote: > On 21 December 2017 at 23:38, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Attached updated set of patches. > > Looks like the new not equals code does not properly take into account > a missing NULL part

Re: [HACKERS] path toward faster partition pruning

On 2017/12/22 1:06, Alvaro Herrera wrote: > Just trying to understand the code here; some very minor comments as I > go along. > > partition_op_strategy returning int32 looks pretty ugly, and the calling > code is not super-intelligible either. How about returning a value from > a new enum? OK,

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 2017/12/25 13:52, Amit Langote wrote: > Hi Alvaro, > > On 2017/12/23 0:10, Alvaro Herrera wrote: >> I believe these are all fixed by the attached delta patch. > > @@ -1676,7 +1694,12 @@ psql_completion(const char *text, int start, int end) >

Re: Unique indexes & constraints on partitioned tables

Hi Alvaro, On 2017/12/23 6:29, Alvaro Herrera wrote: > Hello, > > I'm giving this patch its own thread for mental sanity, but this is > essentially what already posted in [1], plus some doc fixes. This patch > depends on the main "local partitioned indexes" in that thread, last > version of

Re: [HACKERS] path toward faster partition pruning

On 2018/01/04 23:29, Ashutosh Bapat wrote: > On Fri, Dec 29, 2017 at 6:32 PM, Alvaro Herrera > wrote: >> I happened to notice that Ashutosh's patch series at >> https://www.postgresql.org/message-id/CAFjFpReJhFSoy6DqH0ipFSHd=sLNEkSzAtz4VWCaS-w2jZL=u...@mail.gmail.com >>

Re: [HACKERS] path toward faster partition pruning

On 2018/01/05 1:28, Alvaro Herrera wrote: >> From 8d627b910278203151853d324c3319c265cd36c0 Mon Sep 17 00:00:00 2001 >> From: amit >> Date: Tue, 22 Aug 2017 13:48:13 +0900 >> Subject: [PATCH 2/5] Introduce a get_partitions_from_clauses() > > This one fails to apply.

TOAST table created for partitioned tables

Hi. I used to think that $subject didn't happen, but it actually does and ends up consuming a fixed 8192 bytes on the disk. create table p (a int[]) partition by list (a); CREATE TABLE select pg_table_size('p'); pg_table_size --- 8192 (1 row) select

Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables

Thanks for taking a look. On 2018/01/19 14:39, Michael Paquier wrote: > On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote: >> I think having pg_partition_root() and pg_partition_parent() will give >> users enough to get useful views as follows: > > So... pg_parti

Re: [HACKERS] Useless code in ExecInitModifyTable

On 2018/01/19 18:50, Amit Khandekar wrote: > FYI ... > > For the pending update-partition-key patch, we would again require the > rel variable for UPDATE. So in the rebased update-partition-key patch > [1], 'rel' is assigned the root partitioned table. But this time, I > have used the already

Re: Query related to alter table ... attach partition

On 2018/01/23 15:55, Ashutosh Sharma wrote: >> However, we don't make it fail because the table has a constraint that >> contradicts the partition constraint. Attach succeeds in the absence of >> any violating rows and the end result is that the table/partition has >> contradictory constraints

Re: Query related to alter table ... attach partition

On 2018/01/23 14:35, Ashutosh Sharma wrote: > I have created a regular table with CHECK constraint on the partition > key column and it conflicts with the partition constraint but, still, > i could attach the table with the partitioned table. Here is what i am > trying to do, > >

relispartition for index partitions

Hi. I noticed that relispartition isn't set for index's partitions. create table p (a int) partition by list (a); create table p12 partition of p for values in (1, 2); create index on p (a); select relname, relkind from pg_class where relnamespace = 'public'::regnamespace and relispartition is

Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables

On 2018/01/22 11:44, Michael Paquier wrote: > On Sun, Jan 21, 2018 at 07:16:38PM +1300, David Rowley wrote: >> On 20 January 2018 at 23:14, Michael Paquier >> wrote: >>> If pg_partition_tree_tables() uses the top of the partition as input, >>> all the tree should show

Re: Boolean partitions syntax

Hi Stephen. On 2018/01/26 10:16, Stephen Frost wrote: > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > Still compiles and passes regression tests, which is good. Thanks for looking at this. >>> I extended your test a bit to check whether partitions over booleans

Re: TOAST table created for partitioned tables

On Wed, Jan 17, 2018 at 5:32 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jan 16, 2018 at 5:13 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> I used to think that $subject didn't happen, but it actually does and ends >> up consuming

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On Wed, Jan 17, 2018 at 6:19 PM, David Rowley wrote: > On 17 January 2018 at 17:05, David Rowley > wrote: >> 6. Which brings me to; why do we need match_clauses_to_partkey at all? >> classify_partition_bounding_keys seems to

Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables

On 2018/01/17 22:51, Peter Eisentraut wrote: > I'm setting this patch to Returned with feedback. OK. Sorry that I couldn't reply here since the CF started. I have written some code to implement the pg_partition_root() idea you mentioned upthread earlier this week, but hasn't been able to share

Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables

On 2018/01/02 22:45, Peter Eisentraut wrote: > On 12/28/17 16:24, David Rowley wrote: >>> select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid) >>> from pg_class c >>> order by 1 >>> >>> select pg_partition_root(c.oid), sum(pg_table_size(c.oid)) >>> from pg_class c >>> group by

Re: [HACKERS] Useless code in ExecInitModifyTable

On 2018/01/15 11:28, Stephen Frost wrote: > Fujita-san, Amit, > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: >> On 2017/06/21 16:59, Etsuro Fujita wrote: >>> Commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50 added this to >>> ExecInitModifyTable: >&

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/01/12 18:09, David Rowley wrote: > On 10 January 2018 at 17:18, David Rowley > wrote: >> Basically, the changes to add_paths_to_append_rel() are causing >> duplication in partition_rels. [ ... ] > I also noticed earlier that this is still broken in

Re: non-bulk inserts and tuple routing

On 2018/01/24 17:25, Amit Langote wrote: > On 2018/01/20 7:07, Robert Haas wrote: >> On Fri, Jan 19, 2018 at 3:56 AM, Amit Langote wrote: >>> I rebased the patches, since they started conflicting with a recently >>> committed patch [1]. >> >> I think tha

Re: list partition constraint shape

Fujita-san, Thanks for the review. On 2018/01/25 21:17, Etsuro Fujita wrote: > Thanks for the updated patch!  Some minor comments: > > +   /* > +    * Construct an ArrayExpr for the non-null partition > +    * values > +    */ > +  

Re: list partition constraint shape

Fujita-san, Thanks for the review. On 2018/01/23 20:13, Etsuro Fujita wrote: > (2017/12/13 16:38), Amit Langote wrote: >> Attached patch is an attempt at that.  With the patch, instead of >> internally generating an ANY/ALL expression, generate an OR expression >> inste

Re: non-bulk inserts and tuple routing

Fujita-san, Thanks for the review. On 2018/01/25 18:30, Etsuro Fujita wrote: > (2018/01/25 11:11), Amit Langote wrote: >> Rebased again. > > Thanks for the rebased patch! > > The patches apply cleanly and compile successfully, but make check fails > in an assert-enab

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

David, On 2018/01/12 12:30, David Rowley wrote: > Can you also perform a self-review of the patch? Some of the things > I'm picking up are leftovers from a previous version of the patch. We > might never get through this review if you keep leaving those around! Sorry, I will look more closely

Re: [HACKERS] path toward faster partition pruning

Horiguchi-san, Thanks for the review. On 2018/01/30 20:43, Kyotaro HORIGUCHI wrote: > At Tue, 30 Jan 2018 09:57:44 +0900, Amit Langote wrote: >> AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [1]), compiles, and make > I have some random comments on 0002. > > -extract_par

Re: Boolean partitions syntax

On 2018/01/27 1:31, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 26, 2018 at 11:07 AM, Stephen Frost wrote: >>> I've already had two people mention that it'd be neat to have PG support >>> it, so I don't believe it'd go unused. As for if we

Re: list partition constraint shape

Fujita-san, On 2018/01/29 15:15, Etsuro Fujita wrote: > (2018/01/29 9:50), Amit Langote wrote: >> On 2018/01/26 21:31, Etsuro Fujita wrote: >>> Attached is a modified >>> version of the patch.  What do you think about that?  Please let me know. >>> If t

Re: unique indexes on partitioned tables

Hi Alvaro. On 2018/01/23 7:55, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Version 4 of this patch, rebased on today's master. With the latest patch, I noticed what I think is an unintended behavior. create table p (a int, b int) partition by list (a); create table p1 partition of p for

Re: list partition constraint shape

Fujita-san, On 2018/01/26 21:31, Etsuro Fujita wrote: > (2018/01/26 10:15), Amit Langote wrote: >> On 2018/01/25 21:17, Etsuro Fujita wrote: >>> Some minor comments: >>> >>> +   /* >>> +    * Cons

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