Re: [HACKERS] [POC] hash partitioning

On Fri, Nov 10, 2017 at 4:41 AM, Robert Haas wrote: > On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote: >> Fixed in the 0003 patch. > > I have committed this patch set with the attached adjustments. > Thanks a lot for your support & a ton of thanks to all

Re: [HACKERS] [POC] hash partitioning

On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote: > Fixed in the 0003 patch. I have committed this patch set with the attached adjustments. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company hash-adjustments.patch Description: Binary

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:52 PM, Ashutosh Bapat wrote: > Right now partition keys are immutable but we don't have much code > written with that assumption. All the code usually keeps a lock on the > parent till the time they use the information in the partition

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:45 PM, amul sul wrote: > Yes, you are correct, column involved in the partitioning are immutable. > > I was just worried about any change in the partition key column that > might change selected hash function. Any such change, even if it were allowed,

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas wrote: > On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote: >> Although partition constraints become more simple, there isn't any >> performance >> gain with 0005 patch. Also I am little skeptic about logic in

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas wrote: > On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote: >> Although partition constraints become more simple, there isn't any >> performance >> gain with 0005 patch. Also I am little skeptic about logic in

Re: [HACKERS] [POC] hash partitioning

On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote: > Although partition constraints become more simple, there isn't any performance > gain with 0005 patch. Also I am little skeptic about logic in 0005 where we > copied extended hash function info from the partition key, what if

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 31, 2017 at 9:54 AM, Robert Haas wrote: > On Mon, Oct 30, 2017 at 5:52 PM, amul sul wrote: >> Actually, int4[] is also inappropriate type as we have started using a 64bit >> hash function. We need something int8[] which is not available, so

Re: [HACKERS] [POC] hash partitioning

On Mon, Oct 30, 2017 at 5:52 PM, amul sul wrote: > Actually, int4[] is also inappropriate type as we have started using a 64bit > hash function. We need something int8[] which is not available, so that I > have used ANYARRAYOID in the attached patch(0004). I don't know why

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 24, 2017 at 1:21 PM, amul sul wrote: > Updated patch attached. This patch needs a rebase. It appears that satisfies_hash_func is declared incorrectly in pg_proc.h. ProcedureCreate seems to think that provariadic should be ANYOID if the type of the last element is

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 24, 2017 at 5:00 PM, Andres Freund wrote: > On 2017-10-24 12:43:12 +0530, amul sul wrote: >> I tried to get suggested SMHasher[1] test result for the hash_combine >> for 32-bit and 64-bit version. >> >> SMHasher works on hash keys of the form {0}, {0,1}, {0,1,2}...

Re: [HACKERS] [POC] hash partitioning

On 2017-10-24 12:43:12 +0530, amul sul wrote: > I tried to get suggested SMHasher[1] test result for the hash_combine > for 32-bit and 64-bit version. > > SMHasher works on hash keys of the form {0}, {0,1}, {0,1,2}... up to > N=255, using 256-N as the seed, for the hash_combine testing we >

Re: [HACKERS] [POC] hash partitioning

On Fri, Oct 13, 2017 at 3:00 AM, Andres Freund wrote: > On 2017-10-12 17:27:52 -0400, Robert Haas wrote: >> On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote: >> >> In other words, it's not utterly fixed in stone --- we invented >> >>

Re: [HACKERS] [POC] hash partitioning

On Mon, Oct 16, 2017 at 2:36 PM, Ashutosh Bapat wrote: > > Probably we should move changes to partition_bounds_copy() in 0003 to > 0001, whose name suggests so. > We can't do this, hash partition strategy is introduced by 0002. Sorry for the noise. -- Best

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 4:37 PM, amul sul wrote: > On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat > wrote: >> On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote: >> +hash_part? true :

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 17:27:52 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote: > >> In other words, it's not utterly fixed in stone --- we invented > >> --load-via-partition-root primarily to cope with circumstances that > >> could change hash values

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote: >> In other words, it's not utterly fixed in stone --- we invented >> --load-via-partition-root primarily to cope with circumstances that >> could change hash values --- but we sure don't want to be changing it >> with any

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 16:06:11 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 3:43 PM, Andres Freund wrote: > > Are we going to rely on the the combine function to stay the same > > forever after? > > If we change them, it will be a pg_upgrade compatibility break for > anyone

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 3:43 PM, Andres Freund wrote: > Are we going to rely on the the combine function to stay the same > forever after? If we change them, it will be a pg_upgrade compatibility break for anyone using hash-partitioned tables with more than one partitioning

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 10:05:26 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 9:08 AM, amul sul wrote: > > How about combining high 32 bits and the low 32 bits separately as shown > > below? > > > > static inline uint64 > > hash_combine64(uint64 a, uint64 b) > > { > > return

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 9:08 AM, amul sul wrote: > How about combining high 32 bits and the low 32 bits separately as shown > below? > > static inline uint64 > hash_combine64(uint64 a, uint64 b) > { > return (((uint64) hash_combine((uint32) a >> 32, (uint32) b >> 32) <<

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 6:31 AM, Robert Haas wrote: > On Tue, Oct 10, 2017 at 7:07 AM, amul sul wrote: >> How about the attached patch(0003)? >> Also, the dim variable is renamed to natts. > > I'm not sure I believe this comment: > > +/* > +

Re: [HACKERS] [POC] hash partitioning

On 2017/09/30 1:53, Robert Haas wrote: > On Thu, Sep 28, 2017 at 1:54 AM, Amit Langote > wrote: >> I looked into how satisfies_hash_partition() works and came up with an >> idea that I think will make constraint exclusion work. What if we emitted >> the hash

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 7:07 AM, amul sul wrote: > How about the attached patch(0003)? > Also, the dim variable is renamed to natts. I'm not sure I believe this comment: +/* + * We arrange the partitions in the ascending order of their modulus + * and

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat wrote: > On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote: > >>> +hash_part? true : key->parttypbyval[j], >>> +

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 3:40 PM, amul sul wrote: >> >> natts represents the number of attributes, but for the hash partition bound >> we >> are not dealing with the attribute so that I have used short-form of >> dimension, >> thoughts? > > Okay, I think the dimension(dim) is

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote: >> +hash_part? true : key->parttypbyval[j], >> +key->parttyplen[j]); >> parttyplen is the length of partition key attribute, whereas what you want >> here

Re: [HACKERS] [POC] hash partitioning

On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote: > On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat > wrote: >> On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote: >> > > Thanks Ashutosh for your review, please find my comment

Re: [HACKERS] [POC] hash partitioning

On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat wrote: > On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote: > Thanks Ashutosh for your review, please find my comment inline. > >> 0002 few changes in partition-wise join code to support >>

Re: [HACKERS] [POC] hash partitioning

On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote: > 0002 few changes in partition-wise join code to support > hash-partitioned table as well & regression tests. +switch (key->strategy) +{ +case PARTITION_STRATEGY_HASH: +/* + * Indexes

Re: [HACKERS] [POC] hash partitioning

On Sat, Oct 7, 2017 at 5:22 PM, amul sul wrote: > On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen > wrote: >> Hi Amul, >> >> Could you rebase on latest master ? >> > > Sure will post that soon, but before that, I need to test hash partitioning >

Re: [HACKERS] [POC] hash partitioning

On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen wrote: > Hi Amul, > > Could you rebase on latest master ? > Sure will post that soon, but before that, I need to test hash partitioning with recent partition-wise join commit (f49842d1ee), thanks. Regards, Amul --

Re: [HACKERS] [POC] hash partitioning

Hi Amul, On 09/28/2017 05:56 AM, amul sul wrote: It does not really do the partition pruning via constraint exclusion and I don't think anyone is going to use the remainder in the where condition to fetch data and hash partitioning is not meant for that. But I am sure that we could solve this

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 28, 2017 at 1:54 AM, Amit Langote wrote: > I looked into how satisfies_hash_partition() works and came up with an > idea that I think will make constraint exclusion work. What if we emitted > the hash partition constraint in the following form instead:

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 28, 2017 at 11:24 AM, Amit Langote wrote: > On 2017/09/27 22:41, Jesper Pedersen wrote: >> On 09/27/2017 03:05 AM, amul sul wrote: > Attached rebased patch, thanks. > > While reading through the patch I thought it would be better to keep

Re: [HACKERS] [POC] hash partitioning

On 2017/09/27 22:41, Jesper Pedersen wrote: > On 09/27/2017 03:05 AM, amul sul wrote: Attached rebased patch, thanks. >>> While reading through the patch I thought it would be better to keep >>> MODULUS and REMAINDER in caps, if CREATE TABLE was in caps too in order to >>> highlight

Re: [HACKERS] [POC] hash partitioning

On 09/27/2017 03:05 AM, amul sul wrote: Attached rebased patch, thanks. While reading through the patch I thought it would be better to keep MODULUS and REMAINDER in caps, if CREATE TABLE was in caps too in order to highlight that these are "keywords" for hash partition. Also updated some of

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 18, 2017 at 8:55 PM, Jesper Pedersen wrote: > On 09/15/2017 02:30 AM, amul sul wrote: > >> Attached rebased patch, thanks. >> >> > While reading through the patch I thought it would be better to keep > MODULUS and REMAINDER in caps, if CREATE TABLE was in

Re: [HACKERS] [POC] hash partitioning

On 09/15/2017 02:30 AM, amul sul wrote: Attached rebased patch, thanks. While reading through the patch I thought it would be better to keep MODULUS and REMAINDER in caps, if CREATE TABLE was in caps too in order to highlight that these are "keywords" for hash partition. Also updated some

Re: [HACKERS] [POC] hash partitioning

On Fri, Sep 15, 2017 at 4:30 AM, Thom Brown wrote: > On 14 September 2017 at 09:58, amul sul wrote: > > On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen > > wrote: > >> > >> Hi Amul, > >> > >> On 09/08/2017 08:40 AM, amul sul

Re: [HACKERS] [POC] hash partitioning

On 14 September 2017 at 09:58, amul sul wrote: > On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen > wrote: >> >> Hi Amul, >> >> On 09/08/2017 08:40 AM, amul sul wrote: >>> >>> Rebased 0002 against this commit & renamed to 0001, PFA. >>> >> >> This

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 14, 2017 at 2:05 PM, Jesper Pedersen wrote: > However, it is a little bit difficult to follow the dependencies between > different partition patches, so I may not always provide sane feedback, as > seen in [1]. > > [1] >

Re: [HACKERS] [POC] hash partitioning

On 09/14/2017 01:52 PM, Robert Haas wrote: On Thu, Sep 14, 2017 at 1:07 PM, Jesper Pedersen wrote: Yeah, it would be nice to have a syntax like ) PARTITION BY HASH (col) WITH (AUTO_CREATE = 64); But then there also needs to be a way to create the 64 associated

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 14, 2017 at 1:07 PM, Jesper Pedersen wrote: > Yeah, it would be nice to have a syntax like > > ) PARTITION BY HASH (col) WITH (AUTO_CREATE = 64); > > But then there also needs to be a way to create the 64 associated indexes > too for everything to be easy.

Re: [HACKERS] [POC] hash partitioning

On 09/14/2017 12:56 PM, Robert Haas wrote: On Thu, Sep 14, 2017 at 12:54 PM, David Fetter wrote: Should we be pointing the gun away from people's feet by making hash partitions that cover the space automagically when the partitioning scheme[1] is specified? In other words,

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 14, 2017 at 12:54 PM, David Fetter wrote: > Should we be pointing the gun away from people's feet by making hash > partitions that cover the space automagically when the partitioning > scheme[1] is specified? In other words, do we have a good reason to have > only

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 07:43:29AM -0400, Robert Haas wrote: > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > wrote: > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > Given that we have default partition support now, I am wondering > >

Re: [HACKERS] [POC] hash partitioning

Hi, On 09/14/2017 12:05 PM, Robert Haas wrote: On Thu, Sep 14, 2017 at 11:39 AM, Jesper Pedersen wrote: When I do CREATE TABLE mytab ( a integer NOT NULL, b integer NOT NULL, c integer, d integer ) PARTITION BY HASH (b); and create 64 partitions;

Re: [HACKERS] [POC] hash partitioning

On Thu, Sep 14, 2017 at 11:39 AM, Jesper Pedersen wrote: > When I do > > CREATE TABLE mytab ( > a integer NOT NULL, > b integer NOT NULL, > c integer, > d integer > ) PARTITION BY HASH (b); > > and create 64 partitions; > > CREATE TABLE mytab_p00 PARTITION OF

Re: [HACKERS] [POC] hash partitioning

Hi Amul, On 09/14/2017 04:58 AM, amul sul wrote: On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen

Re: [HACKERS] [POC] hash partitioning

On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen wrote: > Hi Amul, > > On 09/08/2017 08:40 AM, amul sul wrote: > >> Rebased 0002 against this commit & renamed to 0001, PFA. >> >> > This patch needs a rebase. > > Thanks for your note. ​ ​ Attached is the patch rebased

Re: [HACKERS] [POC] hash partitioning

Hi Amul, On 09/08/2017 08:40 AM, amul sul wrote: Rebased 0002 against this commit & renamed to 0001, PFA. This patch needs a rebase. Best regards, Jesper -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 5:30 PM, Alvaro Herrera wrote: > Robert Haas wrote: > > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > > wrote: > > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > > > Given that we have

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 8:00 AM, Alvaro Herrera wrote: > How difficult/tedious/troublesome would be to install the missing > partitions if you set hash partitioning with a default partition and > only later on notice that some partitions are missing? I think if the >

Re: [HACKERS] [POC] hash partitioning

Robert Haas wrote: > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > wrote: > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > Given that we have default partition support now, I am wondering > > whether hash partitioned tables also should

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat wrote: >> Rebased 0002 against this commit & renamed to 0001, PFA. > > Given that we have default partition support now, I am wondering > whether hash partitioned tables also should have default partitions. > The way

Re: [HACKERS] [POC] hash partitioning

On Fri, Sep 8, 2017 at 6:10 PM, amul sul wrote: > On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas wrote: >> >> On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote: >> > I've updated patch to use an extended hash function (Commit # >> >

Re: [HACKERS] [POC] hash partitioning

On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas wrote: > On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote: > > I've updated patch to use an extended hash function (Commit # > > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning. > > Committed 0001

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote: > I've updated patch to use an extended hash function (Commit # > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning. Committed 0001 after noticing that Jeevan Ladhe also found that change convenient for default

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 4, 2017 at 4:08 PM, amul sul wrote: > I've updated patch to use an extended hash function (​Commit # > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning. > > I have done some testing with these patches, everything looks fine, attaching sql and out file

Re: [HACKERS] [POC] hash partitioning

I've updated patch to use an extended hash function (​Commit # 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning. Regards, Amul On Thu, Jul 27, 2017 at 5:11 PM, amul sul wrote: > Attaching newer patches rebased against the latest master head. Thanks ! > >

Re: [HACKERS] [POC] hash partitioning

Hi, This is my patch, before I forgot to add attachments, and the following address is also discussed. https://www.postgresql.org/message-id/2017082612390093777512%40highgo.com

Re: [HACKERS] [POC] hash partitioning

Hello Looking at your hash partitioning syntax, I implemented a hash partition in a more concise way, with no need to determine the number of sub-tables, and dynamically add partitions. Description The hash partition's implement is on the basis of the original range / list partition,and

Re: [HACKERS] [POC] hash partitioning

Hi young, On Mon, 28 Aug 2017 15:33:46 +0800 "yang...@highgo.com" wrote: > Hello > > Looking at your hash partitioning syntax, I implemented a hash partition in a > more concise way, with no need to determine the number of sub-tables, and > dynamically add partitions. I

Re: [HACKERS] [POC] hash partitioning

Attaching newer patches rebased against the latest master head. Thanks ! Regards, Amul 0001-Cleanup_v6.patch Description: Binary data 0002-hash-partitioning_another_design-v16.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [POC] hash partitioning

On Wed, Jul 5, 2017 at 4:50 PM, Dilip Kumar wrote: > On Mon, Jul 3, 2017 at 4:39 PM, amul sul wrote: >> Thanks to catching this, fixed in the attached version. > > Few comments on the latest version. > Thanks for your review, please find my comment

Re: [HACKERS] [POC] hash partitioning

On Mon, Jul 3, 2017 at 4:39 PM, amul sul wrote: > Thanks to catching this, fixed in the attached version. Few comments on the latest version. 0001 looks fine, for 0002 I have some comments. 1. + hbounds = (PartitionHashBound * *) palloc(nparts * + sizeof(PartitionHashBound

Re: [HACKERS] [POC] hash partitioning

On Fri, Jun 23, 2017 at 11:19 AM, Yugo Nagata wrote: > On Fri, 23 Jun 2017 13:41:15 +0900 > Yugo Nagata wrote: > >> On Tue, 6 Jun 2017 13:03:58 +0530 >> amul sul wrote: >> >> >> > Updated patch attached. >> >> I looked into the latest

Re: [HACKERS] [POC] hash partitioning

On Fri, Jun 23, 2017 at 10:11 AM, Yugo Nagata wrote: > On Tue, 6 Jun 2017 13:03:58 +0530 > amul sul wrote: > > >> Updated patch attached. > > I looked into the latest patch (v13) and have some comments > althogh they might be trivial. > Thanks for your

Re: [HACKERS] [POC] hash partitioning

On Fri, 23 Jun 2017 13:41:15 +0900 Yugo Nagata wrote: > On Tue, 6 Jun 2017 13:03:58 +0530 > amul sul wrote: > > > > Updated patch attached. > > I looked into the latest patch (v13) and have some comments > althogh they might be trivial. One more

Re: [HACKERS] [POC] hash partitioning

On Tue, 6 Jun 2017 13:03:58 +0530 amul sul wrote: > Updated patch attached. I looked into the latest patch (v13) and have some comments althogh they might be trivial. First, I couldn't apply this patch to the latest HEAD due to a documentation fix and pgintend updates. It

Re: [HACKERS] [POC] hash partitioning

On Tue, Jun 6, 2017 at 2:41 PM, Amit Langote wrote: > Consider an example using the partition hierarchy: > > root (a int, b char, c int) partition by range (a) > > -> level1 from (1) to (10) partition by list (b) > > -> level2 in ('a') parition by range (c) >

Re: [HACKERS] [POC] hash partitioning

On 2017/06/06 17:50, Dilip Kumar wrote: > On Tue, Jun 6, 2017 at 1:03 PM, amul sul wrote: >> May I ask you, how you sure about 8 is an unfit value for t1 relation? >> And what if the value other than 8, for e.g. 7? > > Well, First I created t1 as a leaf relation like below,

Re: [HACKERS] [POC] hash partitioning

On Tue, Jun 6, 2017 at 1:03 PM, amul sul wrote: > May I ask you, how you sure about 8 is an unfit value for t1 relation? > And what if the value other than 8, for e.g. 7? Well, First I created t1 as a leaf relation like below, and I tested insert into t1 with value 8 and it

Re: [HACKERS] [POC] hash partitioning

Hi Dilip, Thanks for review. On Sat, Jun 3, 2017 at 6:54 PM, Dilip Kumar wrote: > On Thu, May 25, 2017 at 9:59 AM, amul sul wrote: >> On Mon, May 22, 2017 at 2:23 PM, amul sul wrote: >>> >>> Updated patch attached. Thanks a lot for

Re: [HACKERS] [POC] hash partitioning

On Thu, May 25, 2017 at 9:59 AM, amul sul wrote: > On Mon, May 22, 2017 at 2:23 PM, amul sul wrote: >> >> Updated patch attached. Thanks a lot for review. >> > Minor fix in the document, PFA. Patch need rebase --- Function header is not consistent with

Re: [HACKERS] [POC] hash partitioning

On Mon, May 22, 2017 at 1:49 AM, Ashutosh Bapat wrote: > The prologue is arranged as one paragraph (with a new line) per > member. Within each paragraph explanation for each partitioning > strategy starts on its own line. One paragraph per member is more >

Re: [HACKERS] [POC] hash partitioning

On Mon, May 22, 2017 at 2:23 PM, amul sul wrote: > > Updated patch attached. Thanks a lot for review. > Minor fix in the document, PFA. Regards, Amul 0002-hash-partitioning_another_design-v12.patch Description: Binary data 0001-Cleanup_v4.patch Description: Binary data --

Re: [HACKERS] [POC] hash partitioning

On Fri, May 19, 2017 at 10:35 PM, Robert Haas wrote: > On Fri, May 19, 2017 at 5:32 AM, amul sul wrote: >> Updated patch attached. 0001-patch rebased against latest head. >> 0002-patch also incorporates code comments and error message changes >> as per

Re: [HACKERS] [POC] hash partitioning

On Fri, May 19, 2017 at 10:35 PM, Robert Haas wrote: > > + * For range and list partitioned tables, datums is an array of datum-tuples > + * with key->partnatts datums each. > + * For hash partitioned tables, it is an array of datum-tuples with 2 datums, > + * modulus and

Re: [HACKERS] [POC] hash partitioning

On Fri, May 19, 2017 at 5:32 AM, amul sul wrote: > Updated patch attached. 0001-patch rebased against latest head. > 0002-patch also incorporates code comments and error message changes > as per Robert's & your suggestions. Thanks ! -if (spec->strategy !=

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 6:54 PM, Ashutosh Bapat wrote: [...] > > Comments on the tests > +#ifdef USE_ASSERT_CHECKING > +{ > +/* > + * Hash partition bound stores modulus and remainder at > + * b1->datums[i][0] and

Re: [HACKERS] [POC] hash partitioning

On 2017/05/19 1:09, Dilip Kumar wrote: > On Wed, May 17, 2017 at 2:07 PM, amul sul wrote: >>> I would suggest "non-zero positive", since that's what we are using in >>> the documentation. >>> >> >> Understood, Fixed in the attached version. > > Why non-zero positive? We do

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 2:07 PM, amul sul wrote: >> I would suggest "non-zero positive", since that's what we are using in >> the documentation. >> > > Understood, Fixed in the attached version. Why non-zero positive? We do support zero for the remainder right? -- Regards,

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 11:51 PM, Robert Haas wrote: > On Wed, May 17, 2017 at 1:41 AM, Ashutosh Bapat > wrote: >>> Fixed in the attached version; used "hash partition remainder must be >>> greater than or equal to 0" instead. >> >> I

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 1:41 AM, Ashutosh Bapat wrote: >> Fixed in the attached version; used "hash partition remainder must be >> greater than or equal to 0" instead. > > I would suggest "non-zero positive", since that's what we are using in > the documentation.

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 2:07 PM, amul sul wrote: > >> In partition_bounds_equal(), please add comments explaining why is it safe to >> check just the indexes? May be we should add code under assertion to make >> sure >> that the datums are equal as well. > > Added assert in

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 11:11 AM, Ashutosh Bapat wrote: > On Wed, May 17, 2017 at 12:04 AM, amul sul wrote: >> On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote: >>> On Tue, May 16, 2017 at 4:22 PM, amul sul

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 12:04 AM, amul sul wrote: > On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote: >> On Tue, May 16, 2017 at 4:22 PM, amul sul wrote: >>> v6 patch has bug in partition oid mapping and indexing, fixed in the >>>

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 9:38 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Tue, May 16, 2017 at 6:50 PM, Peter Eisentraut >> wrote: >>> On 5/15/17 23:45, Ashutosh Bapat wrote: +1. We should throw an

Re: [HACKERS] [POC] hash partitioning

Ashutosh Bapat writes: > On Tue, May 16, 2017 at 6:50 PM, Peter Eisentraut > wrote: >> On 5/15/17 23:45, Ashutosh Bapat wrote: >>> +1. We should throw an error and add a line in documentation that >>> collation should not be

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 6:50 PM, Peter Eisentraut wrote: > On 5/15/17 23:45, Ashutosh Bapat wrote: >> +1. We should throw an error and add a line in documentation that >> collation should not be specified for hash partitioned table. > > Why is it even allowed in

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote: > On Tue, May 16, 2017 at 4:22 PM, amul sul wrote: >> v6 patch has bug in partition oid mapping and indexing, fixed in the >> attached version. >> >> Now partition oids will be arranged in the

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 3:19 AM, Ashutosh Bapat wrote: > While earlier, I thought the same, I am wondering whether this is > true. Don't different collations deem different strings equal e.g one > collation may deem 'aa' and 'AA' as same but other may not. No,

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 4:22 PM, amul sul wrote: > v6 patch has bug in partition oid mapping and indexing, fixed in the > attached version. > > Now partition oids will be arranged in the ascending order of hash > partition bound (i.e. modulus and remainder sorting order)

Re: [HACKERS] [POC] hash partitioning

On 5/16/17 03:19, Ashutosh Bapat wrote: > On Tue, May 16, 2017 at 10:03 AM, amul sul wrote: >> On Mon, May 15, 2017 at 9:13 PM, Robert Haas wrote: > Collation is only relevant for ordering, not equality. > > While earlier, I thought the same, I am

Re: [HACKERS] [POC] hash partitioning

On 5/15/17 23:45, Ashutosh Bapat wrote: > +1. We should throw an error and add a line in documentation that > collation should not be specified for hash partitioned table. Why is it even allowed in the parser then? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 3:30 PM, amul sul wrote: > On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat > wrote: > [...] +if (key->strategy == PARTITION_STRATEGY_HASH) +{ +ndatums = nparts; +

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 1:17 PM, Ashutosh Bapat wrote: > Hi, > Here's patch with some cosmetic fixes to 0002, to be applied on top of 0002. > Thank you, included in v6 patch. Regards, Amul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] [POC] hash partitioning

On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat wrote: [...] >>> >>> +if (key->strategy == PARTITION_STRATEGY_HASH) >>> +{ >>> +ndatums = nparts; >>> +hbounds = (PartitionHashBound **) palloc(nparts * >>> + >>>

  1   2   >