Re: [HACKERS] Runtime Partition Pruning

2017-11-10 Thread amul sul
On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson wrote: > Hello all, > > Here is the updated patch which is rebased over v10 of Amit Langote's > path towards faster pruning patch [1]. It modifies the PartScanKeyInfo > struct to hold expressions which is then evaluated by the

Re: [HACKERS] [POC] hash partitioning

2017-11-09 Thread amul sul
On Fri, Nov 10, 2017 at 4:41 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Nov 1, 2017 at 6:16 AM, amul sul <sula...@gmail.com> wrote: >> Fixed in the 0003 patch. > > I have committed this patch set with the attached adjustments. > Thanks a lot for your su

Re: [HACKERS] path toward faster partition pruning

2017-11-09 Thread amul sul
On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote wrote: > On 2017/11/06 14:32, David Rowley wrote: >> On 6 November 2017 at 17:30, Amit Langote wrote: >>> On 2017/11/03 13:32, David Rowley wrote: On 31 October 2017 at 21:43, Amit Langote wrote: [] > > Attached

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

2017-11-09 Thread amul sul
Hi Dilip, v6 patch: 42 + /* 43 +* Estimate number of hashtable entries we can have within maxbytes. This 44 +* estimates the hash cost as sizeof(PagetableEntry). 45 +*/ 46 + nbuckets = maxbytes / 47 + (sizeof(PagetableEntry) + sizeof(Pointer) + sizeof(Pointer)); It

Re: [HACKERS] [POC] hash partitioning

2017-11-02 Thread amul sul
On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Nov 1, 2017 at 3:46 PM, amul sul <sula...@gmail.com> wrote: >> Although partition constraints become more simple, there isn't any >> performance >> gain with 0005 patch. Als

Re: [HACKERS] [POC] hash partitioning

2017-10-30 Thread amul sul
On Tue, Oct 31, 2017 at 9:54 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Oct 30, 2017 at 5:52 PM, amul sul <sula...@gmail.com> wrote: >> Actually, int4[] is also inappropriate type as we have started using a 64bit >> hash function. We need something int8[]

Re: [HACKERS] [POC] hash partitioning

2017-10-24 Thread amul sul
On Tue, Oct 24, 2017 at 5:00 PM, Andres Freund <and...@anarazel.de> 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 ke

Re: [HACKERS] [POC] hash partitioning

2017-10-24 Thread amul sul
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

2017-10-12 Thread amul sul
On Thu, Oct 12, 2017 at 6:31 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Oct 10, 2017 at 7:07 AM, amul sul <sula...@gmail.com> wrote: >> How about the attached patch(0003)? >> Also, the dim variable is renamed to natts. > > I'

Re: [HACKERS] [POC] hash partitioning

2017-10-10 Thread amul sul
On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Oct 10, 2017 at 3:32 PM, amul sul <sula...@gmail.com> wrote: > >>> +hash_part? true : key->parttypbyval[j], >>> +

Re: [HACKERS] [POC] hash partitioning

2017-10-10 Thread amul sul
On Tue, Oct 10, 2017 at 3:32 PM, amul sul <sula...@gmail.com> wrote: > On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Mon, Oct 9, 2017 at 4:44 PM, amul sul <sula...@gmail.com> wrote: >> > > Thanks Ashuto

Re: [HACKERS] [POC] hash partitioning

2017-10-10 Thread amul sul
On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Mon, Oct 9, 2017 at 4:44 PM, amul sul <sula...@gmail.com> wrote: > Thanks Ashutosh for your review, please find my comment inline. > >> 0002 few changes in partition-wise j

Re: [HACKERS] [POC] hash partitioning

2017-10-09 Thread amul sul
On Sat, Oct 7, 2017 at 5:22 PM, amul sul <sula...@gmail.com> wrote: > On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen > <jesper.peder...@redhat.com> wrote: >> Hi Amul, >> >> Could you rebase on latest master ? >> > > Sure will post that soon, b

Re: [HACKERS] [POC] hash partitioning

2017-10-07 Thread amul sul
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] UPDATE of partition key

2017-09-29 Thread amul sul
On Wed, Sep 13, 2017 at 4:24 PM, amul sul <sula...@gmail.com> wrote: > > > On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila <amit.kapil...@gmail.com> > wrote: >> >> On Fri, Sep 8, 2017 at 4:51 PM, amul sul <sula...@gmail.com> wrote: >> > On Th

Re: [HACKERS] [POC] hash partitioning

2017-09-28 Thread amul sul
On Thu, Sep 28, 2017 at 11:24 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/27 22:41, Jesper Pedersen wrote: >> On 09/27/2017 03:05 AM, amul sul wrote: >>>>> Attached rebased patch, thanks. >>>>> >>>>> >>>&

[HACKERS] Restrict concurrent update/delete with UPDATE of partition key

2017-09-27 Thread amul sul
Hi All, Attaching POC patch that throws an error in the case of a concurrent update to an already deleted tuple due to UPDATE of partition key[1]. In a normal update new tuple is linked to the old one via ctid forming a chain of tuple versions but UPDATE of partition key[1] move tuple from one

Re: [HACKERS] [POC] hash partitioning

2017-09-27 Thread amul sul
On Mon, Sep 18, 2017 at 8:55 PM, Jesper Pedersen <jesper.peder...@redhat.com > 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 an

Re: [HACKERS] path toward faster partition pruning

2017-09-27 Thread amul sul
On Wed, Sep 27, 2017 at 6:09 AM, Amit Langote wrote: > On 2017/09/27 1:51, Robert Haas wrote: > > On Tue, Sep 26, 2017 at 10:57 AM, Jesper Pedersen > > wrote: > >> One could advocate (*cough*) that the hash partition patch [1] should

Re: [HACKERS] Improve catcache/syscache performance.

2017-09-26 Thread amul sul
On Fri, Sep 22, 2017 at 11:47 AM, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2017-09-20 18:26:50 +0530, amul sul wrote: > > Patch 0007: > > Other than these concern, patch looks pretty reasonable to me. > > I'd appreciate if you could have a look a

Re: [HACKERS] UPDATE of partition key

2017-09-21 Thread amul sul
On Wed, Sep 20, 2017 at 9:27 PM, Amit Khandekar wrote: > On 20 September 2017 at 00:06, Robert Haas wrote: > > On Fri, Sep 15, 2017 at 7:25 AM, Amit Khandekar > wrote: > >> [ new patch ] > 86 - (event ==

Re: [HACKERS] Improve catcache/syscache performance.

2017-09-20 Thread amul sul
Patch 0007: 1: 400 + /* 401 +* XXX: might be worthwhile to only handle oid sysattr, to reduce 402 +* overhead - it's the most common key. 403 +*/ IMHO, let fix that as well. I tested this by fixing (see the attach patch) but does not found much gain on my local

Re: [HACKERS] [POC] hash partitioning

2017-09-15 Thread amul sul
On Fri, Sep 15, 2017 at 4:30 AM, Thom Brown <t...@linux.com> wrote: > On 14 September 2017 at 09:58, amul sul <sula...@gmail.com> wrote: > > On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen > > <jesper.peder...@redhat.com> wrote: > >> > >> Hi Amu

Re: [HACKERS] [POC] hash partitioning

2017-09-14 Thread amul sul
On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen <jesper.peder...@redhat.com > 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

Re: [HACKERS] UPDATE of partition key

2017-09-13 Thread amul sul
On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Sep 8, 2017 at 4:51 PM, amul sul <sula...@gmail.com> wrote: > > On Thu, May 18, 2017 at 9:13 AM, Amit Kapila <amit.kapil...@gmail.com> > > wrote: > >> > >

Re: [HACKERS] [POC] hash partitioning

2017-09-11 Thread amul sul
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

2017-09-08 Thread amul sul
On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Sep 4, 2017 at 6:38 AM, amul sul <sula...@gmail.com> wrote: > > I've updated patch to use an extended hash function (Commit # > > 81c5e46c490e2426db243eada186995da5bb0ba7) for the parti

Re: [HACKERS] UPDATE of partition key

2017-09-08 Thread amul sul
On Thu, May 18, 2017 at 9:13 AM, Amit Kapila wrote: > On Wed, May 17, 2017 at 5:17 PM, Robert Haas > wrote: > > On Wed, May 17, 2017 at 6:29 AM, Amit Kapila > wrote: > >> I think we can do this even without using an

Re: [HACKERS] Hash Functions

2017-09-08 Thread amul sul
On Fri, Sep 1, 2017 at 8:01 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Aug 31, 2017 at 8:40 AM, amul sul <sula...@gmail.com> wrote: > > Fixed in the attached version. > > I fixed these up a bit and committed them. Thanks. > > I think t

Re: [HACKERS] [POC] hash partitioning

2017-09-04 Thread amul sul
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 <sula...@gmail.com> wrote: > Attaching newer patches rebased against the latest master hea

Re: [HACKERS] Hash Functions

2017-08-31 Thread amul sul
On Wed, Aug 30, 2017 at 9:05 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Aug 30, 2017 at 10:43 AM, amul sul <sula...@gmail.com> wrote: > > Thanks for the suggestion, I have updated 0002-patch accordingly. > > Using this I found some strange behaviours as

Re: [HACKERS] Hash Functions

2017-08-30 Thread amul sul
On Tue, Aug 29, 2017 at 11:48 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Aug 22, 2017 at 8:14 AM, amul sul <sula...@gmail.com> wrote: > > Attaching patch 0002 for the reviewer's testing. > > I think that this 0002 is not something we can think of c

Re: [HACKERS] Hash Functions

2017-08-29 Thread amul sul
On Tue, Aug 22, 2017 at 5:44 PM, amul sul <sula...@gmail.com> wrote: > On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas <robertmh...@gmail.com> > wrote: > >> On Fri, Aug 18, 2017 at 1:12 PM, amul sul <sula...@gmail.com> wrote: >> > I have a small query,

Re: [HACKERS] Hash Functions

2017-08-22 Thread amul sul
On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Aug 18, 2017 at 1:12 PM, amul sul <sula...@gmail.com> wrote: > > I have a small query, what if I want a cache entry with extended hash > > function instead standard one, I migh

Re: [HACKERS] Hash Functions

2017-08-18 Thread amul sul
On Fri, Aug 18, 2017 at 8:49 AM, Robert Haas wrote: > On Wed, Aug 16, 2017 at 5:34 PM, Robert Haas > wrote: > > Attached is a quick sketch of how this could perhaps be done (ignoring > > for the moment the relatively-boring opclass pushups). > >

Re: [HACKERS] reload-through-the-top-parent switch the partition table

2017-08-08 Thread amul sul
On Tue, Aug 8, 2017 at 6:18 PM, Rushabh Lathia wrote: > Thanks Rajkumar for testing and reporting this. > > > It seems like with we set the numParents and parents only for the > dumpable objects (flagInhTables()). Current patch relies on the numParents > and parents to

Re: [HACKERS] [POC] hash partitioning

2017-07-27 Thread amul sul
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

2017-07-05 Thread amul sul
On Wed, Jul 5, 2017 at 4:50 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Mon, Jul 3, 2017 at 4:39 PM, amul sul <sula...@gmail.com> wrote: >> Thanks to catching this, fixed in the attached version. > > Few comments on the latest version. > Thanks for your

Re: [HACKERS] [POC] hash partitioning

2017-07-03 Thread amul sul
On Fri, Jun 23, 2017 at 11:19 AM, Yugo Nagata <nag...@sraoss.co.jp> wrote: > On Fri, 23 Jun 2017 13:41:15 +0900 > Yugo Nagata <nag...@sraoss.co.jp> wrote: > >> On Tue, 6 Jun 2017 13:03:58 +0530 >> amul sul <sula...@gmail.com> wrote: >> >> >>

Re: [HACKERS] [POC] hash partitioning

2017-07-03 Thread amul sul
On Fri, Jun 23, 2017 at 10:11 AM, Yugo Nagata <nag...@sraoss.co.jp> wrote: > On Tue, 6 Jun 2017 13:03:58 +0530 > amul sul <sula...@gmail.com> wrote: > > >> Updated patch attached. > > I looked into the latest patch (v13) and have some comments > althogh t

Re: [HACKERS] Multi column range partition table

2017-06-22 Thread amul sul
On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/06/22 20:48, amul sul wrote: >> Hi, >> >> While working on the another patch, I came across the case where >> I need an auto generated partition for a mutil-column

[HACKERS] Multi column range partition table

2017-06-22 Thread amul sul
Hi, While working on the another patch, I came across the case where I need an auto generated partition for a mutil-column range partitioned table having following range bound: PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10) PARTITION p2 FROM (10, 10) TO (10, UNBOUNDED) PARTITION p3 FROM

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

2017-06-12 Thread amul sul
On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote: [...] > I committed this with fixes for those issues, plus I renamed the macro > to partition_bound_accepts_nulls, which I think is more clear. > partition_bound_accepts_nulls() will alway yield true for a range

Re: [HACKERS] Adding support for Default partition in partitioning

2017-06-07 Thread amul sul
On Wed, Jun 7, 2017 at 10:30 AM, Jeevan Ladhe wrote: > > >> IIUC, default partition constraints is simply NOT IN (> other sibling partitions>). >> If constraint on the default partition refutes the new partition's >> constraints that means we have overlapping

Re: [HACKERS] Adding support for Default partition in partitioning

2017-06-06 Thread amul sul
On Wed, Jun 7, 2017 at 2:08 AM, Jeevan Ladhe wrote: [...] >> >> The code in check_default_allows_bound() to check whether the default >> partition >> has any rows that would fit new partition looks quite similar to the code >> in >> ATExecAttachPartition() checking

Re: [HACKERS] [POC] hash partitioning

2017-06-06 Thread amul sul
Hi Dilip, Thanks for review. On Sat, Jun 3, 2017 at 6:54 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Thu, May 25, 2017 at 9:59 AM, amul sul <sula...@gmail.com> wrote: >> On Mon, May 22, 2017 at 2:23 PM, amul sul <sula...@gmail.com> wrote: >>> >

Re: [HACKERS] [POC] hash partitioning

2017-05-24 Thread amul sul
On Mon, May 22, 2017 at 2:23 PM, amul sul <sula...@gmail.com> 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 Descripti

Re: [HACKERS] [POC] hash partitioning

2017-05-22 Thread amul sul
On Fri, May 19, 2017 at 10:35 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, May 19, 2017 at 5:32 AM, amul sul <sula...@gmail.com> wrote: >> Updated patch attached. 0001-patch rebased against latest head. >> 0002-patch also incorporates code comments and erro

Re: [HACKERS] [POC] hash partitioning

2017-05-19 Thread amul sul
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

2017-05-17 Thread amul sul
On Wed, May 17, 2017 at 11:11 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, May 17, 2017 at 12:04 AM, amul sul <sula...@gmail.com> wrote: >> On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: >>> On Tue, May

Re: [HACKERS] [POC] hash partitioning

2017-05-16 Thread amul sul
On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Tue, May 16, 2017 at 4:22 PM, amul sul <sula...@gmail.com> wrote: >> v6 patch has bug in partition oid mapping and indexing, fixed in the >> attached version. >> >&

Re: [HACKERS] [POC] hash partitioning

2017-05-16 Thread amul sul
On Tue, May 16, 2017 at 3:30 PM, amul sul <sula...@gmail.com> wrote: > On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: > [...] >>>> >>>> +if (key->strategy == PARTITION_STRATEGY_HASH) &g

Re: [HACKERS] [POC] hash partitioning

2017-05-16 Thread amul sul
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

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

Re: [HACKERS] [POC] hash partitioning

2017-05-15 Thread amul sul
On Mon, May 15, 2017 at 9:13 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, May 15, 2017 at 6:57 AM, amul sul <sula...@gmail.com> wrote: >>> Collation is only relevant for ordering, not equality. Since hash >>> opclasses provide only equality, not

Re: [HACKERS] [POC] hash partitioning

2017-05-15 Thread amul sul
On Wed, May 10, 2017 at 10:13 PM, Robert Haas wrote: > On Wed, May 10, 2017 at 8:34 AM, Ashutosh Bapat > wrote: >> Hash partitioning will partition the data based on the hash value of the >> partition key. Does that require collation?

Re: [HACKERS] [POC] hash partitioning

2017-05-14 Thread amul sul
On Sat, May 13, 2017 at 12:11 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Fri, May 12, 2017 at 6:08 PM, amul sul <sula...@gmail.com> wrote: >> Hi, >> >> Please find the following updated patches attached: > > I have done some testing with the new p

Re: [HACKERS] [POC] hash partitioning

2017-05-14 Thread amul sul
On Fri, May 12, 2017 at 10:39 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Fri, May 12, 2017 at 6:08 PM, amul sul <sula...@gmail.com> wrote: >> Hi, >> >> Please find the following updated patches attached: >> >> 0001-Cleanup.p

Re: [HACKERS] [POC] hash partitioning

2017-05-12 Thread amul sul
On Thu, May 11, 2017 at 9:32 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Wed, May 3, 2017 at 6:39 PM, amul sul <sula...@gmail.com> wrote: >> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas <robertmh...@gmail.com> wrote: >> >>>I spent some time toda

Re: [HACKERS] [POC] hash partitioning

2017-05-12 Thread amul sul
On Wed, May 10, 2017 at 6:04 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, May 3, 2017 at 6:39 PM, amul sul <sula...@gmail.com> wrote: >> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas <robertmh...@gmail.com> wrote: >> >>> >

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

2017-05-09 Thread amul sul
On Tue, May 9, 2017 at 3:51 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Tue, May 9, 2017 at 2:59 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Hi Amul, >> >> On 2017/05/09 16:13, amul sul wrote: >>> Hi, >>&g

[HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

2017-05-09 Thread amul sul
Hi, Current pg_dump --exclude-table option excludes partitioned relation and dumps all its child relations and vice versa for --table option, which I think is incorrect. In this case we might need to explore all partitions and exclude or include from dump according to given pg_dump option,

Re: [HACKERS] Adding support for Default partition in partitioning

2017-05-04 Thread amul sul
On Tue, May 2, 2017 at 9:33 PM, Rahila Syed wrote: > Please find attached updated patch with review comments by Robert and Jeevan > implemented. > Patch v8 got clean apply on latest head but server got crash at data insert in the following test: -- Create test table

Re: [HACKERS] [POC] hash partitioning

2017-05-03 Thread amul sul
On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote: >I spent some time today looking at these patches. It seems like there >is some more work still needed here to produce something committable >regardless of which way we go, but I am inclined to think that Amul's >patch

Re: [HACKERS] [POC] hash partitioning

2017-03-03 Thread amul sul
On Fri, Mar 3, 2017 at 5:00 PM, Greg Stark <st...@mit.edu> wrote: > On 2 March 2017 at 13:03, amul sul <sula...@gmail.com> wrote: > > create table foo (a integer, b text) partition by hash (a); > > create table foo1 partition of foo with (modulus 4, remainder 0); >

Re: [HACKERS] [POC] hash partitioning

2017-03-02 Thread amul sul
On Wed, Mar 1, 2017 at 3:50 PM, Yugo Nagata wrote: > ​[]​ > > I Agree that it is unavoidable partitions number in modulo hashing, > > but we can do in other hashing technique. Have you had thought about > > Linear hashing[1] or Consistent hashing​[2]?​ This will allow

Re: [HACKERS] [POC] hash partitioning

2017-02-28 Thread amul sul
On Tue, Feb 28, 2017 at 8:03 PM, Yugo Nagata wrote: > Hi all, > > Now we have a declarative partitioning, but hash partitioning is not > implemented yet. Attached is a POC patch to add the hash partitioning > feature. I know we will need more discussions about the syntax and

Re: [HACKERS] Bug in to_timestamp().

2017-02-15 Thread Amul Sul
The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Review of v7 patch: - Patch applies to the top of master HEAD

Re: [HACKERS] Declarative partitioning - another take

2017-02-08 Thread amul sul
About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch, following test is already covered in alter_table.sql @ Line # 1918, instead of this kindly add test for list_partition: 77 +-- cannot drop NOT NULL constraint of a range partition key column 78 +ALTER TABLE range_parted ALTER a

Re: [HACKERS] Declarative partitioning - another take

2017-02-08 Thread amul sul
Hi Amit, Regarding following code in ATExecDropNotNull function, I don't see any special check for RANGE partitioned, is it intended to have same restriction for LIST partitioned too, I guess not? /* * If the table is a range partitioned table, check that the column is not * in the

Re: [HACKERS] Constraint exclusion failed to prune partition in case of partition expression involves function call

2017-02-04 Thread amul sul
I see, thanks Amit. Regards, Amul Sent from a mobile device. Please excuse brevity and tpyos.

[HACKERS] Constraint exclusion failed to prune partition in case of partition expression involves function call

2017-02-02 Thread amul sul
Hi, In following case, constraint exclusion not able prune partition (even if function is immutable), is this know behaviour? --CASE 1 : create table & insert data create table foo_list (a integer, b text) partition by list (abs(a)); create table foo_list1 partition of foo_list for values in

Re: [HACKERS] pg_background contrib module proposal

2017-01-12 Thread amul sul
On Tue, Jan 10, 2017 at 7:09 AM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 1/9/17 7:22 AM, amul sul wrote: >> >> On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby <jim.na...@bluetreble.com> >> wrote: >>> >>> >> [skipped...] >>> >

Re: [HACKERS] pg_background contrib module proposal

2017-01-09 Thread amul sul
On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby wrote: > [skipped...] > > Oh, hmm. So I guess if you do that when the background process is idle it's > the same as a close? > > I think we need some way to safeguard against accidental forkbombs for cases > where users aren't

Re: [HACKERS] Declarative partitioning - another take

2017-01-09 Thread amul sul
Hi, I got server crash due to assert failure at ATTACHing overlap rang partition, here is test case to reproduce this: CREATE TABLE test_parent(a int) PARTITION BY RANGE (a); CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES FROM(100) TO(200); CREATE TABLE test_parent_part1(a

Re: [HACKERS] pg_background contrib module proposal

2017-01-07 Thread amul sul
On Sat, Jan 7, 2017 at 2:06 PM, Andrew Borodin <boro...@octonica.com> wrote: > Hi! > > 2017-01-07 11:44 GMT+05:00 amul sul <sula...@gmail.com>: > >> Changes: >> 1. pg_background_launch renamed to pg_background_start >> 2. pg_background_detach renamed

Re: [HACKERS] pg_background contrib module proposal

2017-01-06 Thread amul sul
Hi all, Attaching latest pg_background patch for review as per design proposed on 22 Dec '16 with following minor changes in the api. Changes: 1. pg_background_launch renamed to pg_background_start 2. pg_background_detach renamed to pg_background_close 3. Added new api to display previously

Re: [HACKERS] background sessions

2017-01-04 Thread amul sul
On Wed, Jan 4, 2017 at 2:57 PM, Andrew Borodin <boro...@octonica.com> wrote: > 2017-01-04 10:23 GMT+05:00 amul sul <sula...@gmail.com>: >> One more query, can we modify >> BackgroundSessionStart()/BackgroundSession struct to get background >> worker PID as well? &

Re: [HACKERS] background sessions

2017-01-03 Thread amul sul
On Tue, Jan 3, 2017 at 11:36 PM, Andrew Borodin <boro...@octonica.com> wrote: > 2017-01-03 19:39 GMT+05:00 Peter Eisentraut > <peter.eisentr...@2ndquadrant.com>: >> >> On 1/3/17 1:26 AM, amul sul wrote: >> > One more requirement for pg_background i

Re: [HACKERS] background sessions

2017-01-02 Thread amul sul
On Fri, Dec 30, 2016 at 3:48 AM, Peter Eisentraut wrote: > On 12/16/16 10:38 AM, Andrew Borodin wrote: >> 2016-12-16 20:17 GMT+05:00 Peter Eisentraut >> : And one more thing... Can we have BackgroundSessionExecute()

Re: [HACKERS] pg_background contrib module proposal

2016-12-22 Thread amul sul
References : [1] https://www.postgresql.org/message-id/e1c2d331-ee6a-432d-e9f5-dcf85cffaf29%402ndquadrant.com. Regards, Amul Sul 0002-pg_background_worker_as_client_of_bgsession_trial.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] pg_background contrib module proposal

2016-12-19 Thread amul sul
On Tue, Dec 20, 2016 at 12:21 AM, David Fetter <da...@fetter.org> wrote: > On Thu, Nov 24, 2016 at 09:16:53AM +0530, amul sul wrote: >> Hi All, >> >> I would like to take over pg_background patch and repost for >> discussion and review. > > This looks grea

Re: [HACKERS] background sessions

2016-12-14 Thread amul sul
On Thu, Dec 15, 2016 at 12:24 PM, Andrew Borodin wrote: > 2016-12-15 0:30 GMT+05:00 Peter Eisentraut : > TryBeginSession()? What exactly would that do? >>> Return status (success\failure) and session object, if a function

Re: [HACKERS] pg_background contrib module proposal

2016-12-13 Thread amul sul
On Tue, Dec 13, 2016 at 2:05 PM, Andrew Borodin <boro...@octonica.com> wrote: > 2016-12-13 12:55 GMT+05:00 amul sul <sula...@gmail.com>: >> I think background-session code is not that much deviated from >> pg_background code, > It is not derived, though it is not much

Re: [HACKERS] pg_background contrib module proposal

2016-12-12 Thread amul sul
On Mon, Dec 12, 2016 at 10:47 PM, Andrew Borodin wrote: > Hi! > Thanks a lot for your review. > Just in case you'd like to include sleepsort as a test, here it is > wrapped as a regression test(see attachment). But it has serious > downside: it runs no less than 5 seconds.

[HACKERS] pg_background contrib module proposal

2016-11-23 Thread amul sul
Hi All, I would like to take over pg_background patch and repost for discussion and review. Initially Robert Haas has share this for parallelism demonstration[1] and abandoned later with summary of open issue[2] with this pg_background patch need to be fixed, most of them seems to be addressed

Re: [HACKERS] Exclude pg_largeobject form pg_dump

2016-11-16 Thread Amul Sul
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Patch v6 looks good to me, passing to committer. Thanks ! The

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

2016-11-06 Thread amul sul
r). > I am not agree to having this paragraph either, I'll leave the decision to committer. > I'll change the status to needs review. The new status of this patch is: Ready for Committer Regards, Amul Sul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

2016-11-03 Thread amul sul
PostgreSQL also relies on the operating system cache, it is unlikely that an allocation of more than I may be wrong here, would like know your and/or community's thought on this. Thanks. Regards, Amul Sul The new status of this patch is: Waiting on Author -- Sent via pgsql-hackers mailing

Re: [HACKERS] Exclude pg_largeobject form pg_dump

2016-11-03 Thread amul sul
Kindly ignore this, i've added this note to original thread. Sorry for noise. Regards, Amul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Exclude pg_largeobject form pg_dump

2016-11-03 Thread amul sul
Hi Guillaume, With your v2 patch, -B options working as expected but --no-blobs options is still unrecognized, this happens is because of you have forgot to add entry for 'no-blobs' in long_options[] array. Apart from this concern patch looks good to me. Thanks Regards, Amul -- Sent via

Re: [HACKERS] Query regarding selectDumpableExtension()

2016-10-31 Thread amul sul
On 31 Oct 2016 6:48 pm, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > amul sul <sula...@gmail.com> writes: > > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmh...@gmail.com> wrote: > >> There's a comment in dumpExtension() that explains it. >

Re: [HACKERS] Query regarding selectDumpableExtension()

2016-10-31 Thread amul sul
On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Oct 27, 2016 at 2:11 AM, amul sul <sula...@gmail.com> wrote: >> selectDumpableExtension() function skip >> s dump of >> built-in extensions in case of binary-upgrade o

[HACKERS] Query regarding selectDumpableExtension()

2016-10-27 Thread amul sul
Hi ​,​ ​ selectDumpableExtension() function skip ​s dump of​ built-in extensions in case of binary-upgrade only, ​ ​ why not in normal ​dump​ ? ​ ​ Can't we assume those will already be installed in the target database ​ at restore ? Thanks ​ & Regards, Amul​

Re: [HACKERS] Bug in to_timestamp().

2016-09-29 Thread Amul Sul
to me, code in v6 does not differ much from v4 patch. Ready for committer review. Thanks ! Regards, Amul Sul The new status of this patch is: Ready for Committer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Bug in to_timestamp().

2016-09-29 Thread amul sul
On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: > Artur Zakirov writes: >> - now DCH_cache_getnew() is called after parse_format(). Because now >> parse_format() can raise an error and in the next attempt >> DCH_cache_search() could return broken

Re: [HACKERS] Bug in to_timestamp().

2016-09-28 Thread amul sul
On Fri, Sep 16, 2016 at 10:01 PM, Artur Zakirov <a.zaki...@postgrespro.ru> wrote: > On 25.08.2016 13:26, amul sul wrote: >>> >>> Thanks. I've created the entry in >>> https://commitfest.postgresql.org/10/713/ >>> . You can add yourself as a revie

Re: [HACKERS] Fix some corner cases that cube_in rejects

2016-09-27 Thread Amul Sul
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Note for committer : There are unnecessary files (cube_1.out,

Re: [HACKERS] Bug in to_timestamp().

2016-08-25 Thread amul sul
You can add yourself as a reviewer. > Done, added myself as reviewer & changed status to "Ready for Committer". Thanks ! Regards, Amul Sul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in to_timestamp().

2016-08-25 Thread amul sul
NVAL ) to >> prev_type at following line: >> >> 256 + prev_type; > > >You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to >execute such query: > > >SELECT to_timestamp('---2000JUN', ' MON'); > > >Will be it a proper be

  1   2   >