Re: [HACKERS] pow support for pgbench

I don't want to go too deep into it, but you get stuff like this: Select pow(2.0, -3)::text = pow(2, -3)::text; Sure. It does so with any overloaded operator or function: fabien=# SELECT (2.0 + 3)::TEXT = (2 + 3)::TEXT; # f Patch applies, make check ok in pgbench, doc gen ok. ipow code

Re: [HACKERS] pow support for pgbench

Hi, Indeed, this is quite strange... I don't want to go too deep into it, but you get stuff like this: Select pow(2.0, -3)::text = pow(2, -3)::text; ?column? -- f (1 row) - you can simplify the ipow function by removing handling of y<0 case, >maybe add an assert to be sure

Re: [HACKERS] pow support for pgbench

Hello, Sorry for the confusion, I wasn't aware that SQL pow changed types depending on the input value. Indeed, this is quite strange... fabien=# SELECT i, POW(2, i) FROM generate_series(-2, 2) AS i; -2 | 0.25 -1 | 0.5 0 | 1 1 | 2 2 | 4 I've modified the function to

Re: [HACKERS] pow support for pgbench

Hi Fabien, Sorry for the confusion, I wasn't aware that SQL pow changed types depending on the input value. I've modified the function to match more closely the behaviour of SQL, except that 0^(negative) returns 'double inf'. Do you think there is any value in raising an error instead? On Mon,

Re: [HACKERS] pow support for pgbench

Hi Fabien, Thanks for the review. I've fixed the documentation and added an ipow function that handles both positive and negative ints, having 0^0 == 1 and 0^(negative) == PG_INT64_MAX since that's what my glibc math.h pow() is returning. On Sat, Nov 4, 2017 at 12:34 PM, Fabien COELHO

Re: [HACKERS] pow support for pgbench

Hello Raúl, I've fixed the documentation and added an ipow function that handles both positive and negative ints, having 0^0 == 1 and 0^(negative) == PG_INT64_MAX since that's what my glibc math.h pow() is returning. From the comment: * For exp < 0 return 0 except when the base is 1 or

Re: [HACKERS] pow support for pgbench

Hello Raúl, Sorry about the patch. Attaching it now so it can be considered as submitted. There is a typo in the XML doc: 1024.0/ Please check that the documentation compiles. I'm at odds with having the integer version rely on a double pow(), even if it works. I think that there

Re: [HACKERS] GnuTLS support

On 09/18/2017 07:04 PM, Jeff Janes wrote:> You fixed the first issue, but I still get the second one: be-secure-gnutls.c: In function 'get_peer_certificate': be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared (first use in this function) be-secure-gnutls.c:667: error: (Each

Re: [HACKERS] pow support for pgbench

Hello Michaël, I'm fine with having pow in pgbench. I am adding as well Fabien in CC who worked in getting the internal function infrastructure in the shape it is now (waaay better) with commit 86c43f4. It might be even better if https://commitfest.postgresql.org/15/985/, which has been

Re: [HACKERS] pow support for pgbench

Sorry about the patch. Attaching it now so it can be considered as submitted. -- *Raúl Marín Rodríguez*carto.com From a6eecfe6637bdb0cbb02a9eda7b88d9c4325bb51 Mon Sep 17 00:00:00 2001 From: Raul Marin Date: Fri, 13 Oct 2017 17:42:23 +0200 Subject: [PATCH] Add pow()

Re: [HACKERS] pow support for pgbench

Hi, both patches seem complementary. I've rebased my changes on top of that patch (v14) in https://git.io/vFtnT and everything seems to be working fine. On Mon, Oct 30, 2017 at 12:36 PM, Michael Paquier wrote: > On Mon, Oct 30, 2017 at 11:07 AM, Alvaro Herrera >

Re: [HACKERS] pow support for pgbench

Michael Paquier wrote: > Attaching patches directly to a thread is a better practice as if > github goes away, any Postgres developers can still have an access to > any code you publish using the public archives on postgresql.org. Also, by posting to pgsql-hackers indicating intention to

Re: [HACKERS] pow support for pgbench

On Mon, Oct 30, 2017 at 11:56 AM, Raúl Marín Rodríguez wrote: > both patches seem complementary. I've rebased my changes on top of that > patch > (v14) in https://git.io/vFtnT and everything seems to be working fine. Attaching patches directly to a thread is a better

Re: [HACKERS] pow support for pgbench

On Mon, Oct 30, 2017 at 11:07 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> Please add this patch to the upcoming commit fest if you would like to >> get some feedback: >> https://commitfest.postgresql.org/15/ >> >> I am adding as well Fabien in CC who worked in

Re: [HACKERS] pow support for pgbench

Michael Paquier wrote: > Please add this patch to the upcoming commit fest if you would like to > get some feedback: > https://commitfest.postgresql.org/15/ > > I am adding as well Fabien in CC who worked in getting the internal > function infrastructure in the shape it is now (waaay better)

Re: [HACKERS] pow support for pgbench

On Fri, Oct 27, 2017 at 4:51 PM, Raúl Marín Rodríguez wrote: > I've written a small patch to add support for pow() in pgbench. Cool. > The main reason behind it is that I'm currently using a shell call to do it > which takes between 2-10 ms that can be a big percentage of

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

On 2017/10/26 16:40, Etsuro Fujita wrote: Other changes I made to the executor are: (1) currently, we set the RT index for the root partitioned table to ri_RangeTableIndex of partitions' ResultRelInfos, but the proposed EXPLAIN requires that the partition's ri_RangeTableIndex is set to the RT

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

Hi Maksim, On 2017/10/02 21:37, Maksim Milyutin wrote: On 11.09.2017 16:01, Etsuro Fujita wrote: * Query planning: the patch creates copies of Query/Plan with a foreign partition as target from the original Query/Plan for each foreign partition and invokes PlanForeignModify with those copies,

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

Hi Fujita-san! On 11.09.2017 16:01, Etsuro Fujita wrote: Here is an updated version of the patch. * Query planning: the patch creates copies of Query/Plan with a foreign partition as target from the original Query/Plan for each foreign partition and invokes PlanForeignModify with those

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

> On 11 Apr 2017, at 10:55, Etsuro Fujita wrote: > > On 2017/04/07 22:54, Arthur Zakirov wrote: >> Marked the patch as "Ready for Commiter". But the patch should be >> commited only after the patch [1]. > > Thanks for reviewing! I'll continue to work on this for

Re: [HACKERS] GnuTLS support

On Sun, Sep 17, 2017 at 2:17 PM, Andreas Karlsson wrote: > On 09/15/2017 06:55 PM, Jeff Janes wrote: > >> I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9 >> > > Thanks for testing my patch. I have fixed both these issues plus some of > the other feedback. A

Re: [HACKERS] GnuTLS support

On 09/15/2017 06:55 PM, Jeff Janes wrote: I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9 Thanks for testing my patch. I have fixed both these issues plus some of the other feedback. A new version of my patch is attached which should, at least on theory, support all GnuTLS

Re: [HACKERS] GnuTLS support

On Thu, Aug 31, 2017 at 10:52 AM, Andreas Karlsson wrote: > > > > = Work left to do > > - Test code with older versions of GnuTLS > I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9 be-secure-gnutls.c: In function 'be_tls_init': be-secure-gnutls.c:168:

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

On 2017/08/17 17:27, Etsuro Fujita wrote: On 2017/07/11 6:56, Robert Haas wrote: I have to admit that I'm a little bit fuzzy about why foreign insert routing requires all of these changes.  I think this patch would benefit from being accompanied by several paragraphs of explanation outlining

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

On Sat, Sep 9, 2017 at 3:05 AM, Robert Haas wrote: > On Fri, Sep 8, 2017 at 10:08 AM, Jeevan Ladhe > wrote: > > Thanks Robert for taking care of this. > > My V29 patch series[1] is based on this commit now. > > Committed 0001-0003, 0005 with

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

On Fri, Sep 8, 2017 at 10:08 AM, Jeevan Ladhe wrote: > Thanks Robert for taking care of this. > My V29 patch series[1] is based on this commit now. Committed 0001-0003, 0005 with assorted modifications, mostly cosmetic, but with some actual changes to

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

On Fri, Sep 8, 2017 at 6:46 AM, Robert Haas wrote: > On Thu, Sep 7, 2017 at 8:13 AM, Jeevan Ladhe > wrote: > > The fix would be much easier if the refactoring patch 0001 by Amul in > hash > > partitioning thread[2] is committed. > > Done. >

Re: [HACKERS] GnuTLS support

On Thu, Sep 7, 2017 at 10:35 PM, Tom Lane wrote: > I think we might be best off just playing it straight and providing > a config file that contains a section along these lines: > > # Parameters for OpenSSL. Leave these commented out if not using OpenSSL. > # > #ssl_ciphers =

Re: [HACKERS] GnuTLS support

Andreas Karlsson writes: > On 09/07/2017 11:34 PM, Tomas Vondra wrote: >> Well, people won't be able to set the inactive options, just like you >> can't set ssl=on when you build without OpenSSL support. But perhaps we >> could simply not include the inactive options into the

Re: [HACKERS] GnuTLS support

On 09/07/2017 11:34 PM, Tomas Vondra wrote: I am worried about having 3x version of TLS controls in postgresql.conf, and only one set being active. Perhaps we need to break out the TLS config to separate files or something. Anyway, this needs more thought. Well, people won't be able to set the

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

On Thu, Sep 7, 2017 at 8:13 AM, Jeevan Ladhe wrote: > The fix would be much easier if the refactoring patch 0001 by Amul in hash > partitioning thread[2] is committed. Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: [HACKERS] GnuTLS support

On Thu, Sep 7, 2017 at 2:34 PM, Tomas Vondra wrote: > Hi, > > On 09/04/2017 04:24 PM, Bruce Momjian wrote: > > On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote: > >> I think that what this shows is that the current set of GUCs is overly > >>

Re: [HACKERS] GnuTLS support

Hi, On 09/04/2017 04:24 PM, Bruce Momjian wrote: > On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote: >> I think that what this shows is that the current set of GUCs is overly >> OpenSSL-centric. We created a set of GUCs that are actually specific >> to one particular implementation

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

On Wed, Sep 6, 2017 at 5:50 PM, Jeevan Ladhe wrote: > >> >> I am wondering whether we could avoid call to get_default_partition_oid() >> in >> the above block, thus avoiding a sys cache lookup. The sys cache search >> shouldn't be expensive since the cache should

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

On Thu, Sep 7, 2017 at 3:15 PM, Rajkumar Raghuwanshi < rajkumar.raghuwan...@enterprisedb.com> wrote: > On Wed, Sep 6, 2017 at 5:25 PM, Jeevan Ladhe < > jeevan.la...@enterprisedb.com> wrote: > >> Hi, >> >> Attached is the rebased set of patches. >> Robert has committed[1] patch 0001 in V26 series,

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

On Wed, Sep 6, 2017 at 5:25 PM, Jeevan Ladhe wrote: > Hi, > > Attached is the rebased set of patches. > Robert has committed[1] patch 0001 in V26 series, hence the patch numbering > in V27 is now decreased by 1 for each patch as compared to V26. > Hi, I have

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

Hi Ashutosh, I have tried to address your comments in V27 patch series[1]. Please find my comments inlined. > >> > >> The current set of patches contains 6 patches as below: > >> > >> 0001: > >> Refactoring existing ATExecAttachPartition code so that it can be used > >> for > >> default

Re: [HACKERS] GnuTLS support

On Fri, Sep 01, 2017 at 10:33:37PM +0200, Alvaro Herrera wrote: > Tom Lane wrote: > > Robert Haas writes: > > > On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson > > > wrote: > > > >> There are currently two failing SSL tests which at least to me seems

Re: [HACKERS] GnuTLS support

On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote: > I think that what this shows is that the current set of GUCs is overly > OpenSSL-centric. We created a set of GUCs that are actually specific > to one particular implementation but named them as if they were > generic. My idea about

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

On Sat, Sep 2, 2017 at 7:03 AM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 3:19 PM, Robert Haas wrote: > > On Thu, Aug 31, 2017 at 8:53 AM, Jeevan Ladhe > > wrote: > >> 0001: > >> This patch refactors

Re: [HACKERS] GnuTLS support

Tom Lane wrote: > Robert Haas writes: > > On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: > >> There are currently two failing SSL tests which at least to me seems more > >> like they test specific OpenSSL behaviors rather than something which

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

On Fri, Sep 1, 2017 at 3:19 PM, Robert Haas wrote: > On Thu, Aug 31, 2017 at 8:53 AM, Jeevan Ladhe > wrote: >> 0001: >> This patch refactors RelationBuildPartitionDesc(), basically this is patch >> 0001 of default range partition[1]. > > I

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

On Thu, Aug 31, 2017 at 8:53 AM, Jeevan Ladhe wrote: > 0001: > This patch refactors RelationBuildPartitionDesc(), basically this is patch > 0001 of default range partition[1]. I spent a while studying this; it seems to be simpler and there's no real downside. So,

Re: [HACKERS] GnuTLS support

> On 01 Sep 2017, at 20:00, Robert Haas wrote: > > On Fri, Sep 1, 2017 at 1:10 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: I have seen

Re: [HACKERS] GnuTLS support

On Fri, Sep 1, 2017 at 1:10 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: >>> I have seen discussions from time to time about OpenSSL and its licensing >>> issues so I decided

Re: [HACKERS] GnuTLS support

> On 01 Sep 2017, at 19:10, Tom Lane wrote: > > Robert Haas writes: >> On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: > >>> There are currently two failing SSL tests which at least to me seems more >>> like they test

Re: [HACKERS] GnuTLS support

Robert Haas writes: > On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: >> I have seen discussions from time to time about OpenSSL and its licensing >> issues so I decided to see how much work it would be to add support for >> another TLS library,

Re: [HACKERS] GnuTLS support

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: > I have seen discussions from time to time about OpenSSL and its licensing > issues so I decided to see how much work it would be to add support for > another TLS library, and I went with GnuTLS since it is the library

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

On 2017/08/26 1:43, Robert Haas wrote: On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita wrote: I agree, but I wonder if we ought to make it work first using the existing APIs and then add these new APIs as an optimization. I'm not sure that's a good idea because

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

On Mon, Aug 21, 2017 at 4:47 PM, Jeevan Ladhe wrote: > > Hi, > > On Thu, Aug 17, 2017 at 3:29 PM, Jeevan Ladhe > wrote: >> >> Hi, >> >> On Tue, Aug 15, 2017 at 7:20 PM, Robert Haas >> wrote: >>> >>> On Wed, Jul

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

On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita wrote: >> I agree, but I wonder if we ought to make it work first using the >> existing APIs and then add these new APIs as an optimization. > > I'm not sure that's a good idea because that once we support INSERT >

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

On 2017/08/19 2:12, Robert Haas wrote: On Thu, Aug 17, 2017 at 4:27 AM, Etsuro Fujita wrote: I think that would be much more efficient than INSERTing tuples into the remote server one by one. What do you think about that? I agree, but I wonder if we ought to

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

On 2017/08/18 22:41, David Fetter wrote: On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote: On 2017/08/17 23:48, David Fetter wrote: On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote: On 2017/07/11 6:56, Robert Haas wrote: On Thu, Jun 29, 2017 at 6:20 AM, Etsuro

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

On Thu, Aug 17, 2017 at 4:27 AM, Etsuro Fujita wrote: > I think that would be much more efficient than INSERTing tuples into the > remote server one by one. What do you think about that? I agree, but I wonder if we ought to make it work first using the existing APIs

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

On Thu, Aug 17, 2017 at 7:58 AM, Etsuro Fujita wrote: >> The description seems to support only COPY to a foreign table from a >> file, but probably we need the support other way round as well. This >> looks like a feature (support copy to and from a foreign table) to

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

On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote: > On 2017/08/17 23:48, David Fetter wrote: > >On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote: > >>On 2017/07/11 6:56, Robert Haas wrote: > >>>On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita >

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

On 2017/08/17 23:48, David Fetter wrote: On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote: On 2017/07/11 6:56, Robert Haas wrote: On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita wrote: So, I dropped the COPY part. Ouch. I think we should try to

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

On Fri, Aug 18, 2017 at 12:25 AM, Robert Haas wrote: > On Thu, Aug 17, 2017 at 6:24 AM, Jeevan Ladhe > wrote: > > I have addressed following comments in V25 patch[1]. > > Committed 0001. Since that code seems to be changing about every 10 >

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

On Thu, Aug 17, 2017 at 6:24 AM, Jeevan Ladhe wrote: > I have addressed following comments in V25 patch[1]. Committed 0001. Since that code seems to be changing about every 10 minutes, it seems best to get this refactoring out of the way before it changes again.

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

On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote: > On 2017/07/11 6:56, Robert Haas wrote: > >On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita > > wrote: > >>So, I dropped the COPY part. > > > >Ouch. I think we should try to figure out how the COPY part

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

On 17 August 2017 at 10:59, Jeevan Ladhe wrote: > Hi, > > On Tue, Aug 15, 2017 at 7:20 PM, Robert Haas wrote: >> >> On Wed, Jul 26, 2017 at 8:14 AM, Jeevan Ladhe >> wrote: >> > I have rebased the patches on the

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

On 2017/08/17 20:37, Ashutosh Bapat wrote: On Thu, Aug 17, 2017 at 1:57 PM, Etsuro Fujita wrote: I spent some time on this. To handle that, I'd like to propose doing something similar to \copy (frontend copy): submit a COPY query "COPY ... FROM STDIN" to the

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

On Thu, Aug 17, 2017 at 1:57 PM, Etsuro Fujita wrote: > On 2017/07/11 6:56, Robert Haas wrote: >> >> On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita >> wrote: >>> >>> So, I dropped the COPY part. >> >> >> Ouch. I think we should try to

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

Hi Robert, >> > 0007: > >> > This patch introduces code to check if the scanning of default > partition > >> > child > >> > can be skipped if it's constraints are proven. > >> > >> If I understand correctly, this is actually a completely separate > >> feature not intrinsically related to default

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

Hi Robert, Please find my feedback inlined. I have addressed following comments in V25 patch[1]. > > 0002: > > This patch teaches the partitioning code to handle the NIL returned by > > get_qual_for_list(). > > This is needed because a default partition will not have any constraints > in > >

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

Hi Ashutosh, On Thu, Aug 17, 2017 at 3:41 PM, Jeevan Ladhe wrote: > Hi Ashutosh, > > Please find my feedback inlined. > > On Fri, Jul 28, 2017 at 7:00 PM, Ashutosh Bapat < > ashutosh.ba...@enterprisedb.com> wrote: > >> On Wed, Jul 26, 2017 at 5:44 PM, Jeevan

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

Hi Ashutosh, Please find my feedback inlined. On Fri, Jul 28, 2017 at 7:00 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Jul 26, 2017 at 5:44 PM, Jeevan Ladhe > wrote: > > Hi, > > > > I have rebased the patches on the latest commit. > > >

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

On 2017/07/11 6:56, Robert Haas wrote: On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita wrote: So, I dropped the COPY part. Ouch. I think we should try to figure out how the COPY part will be handled before we commit to a design. I spent some time on this. To

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

On Wed, Jul 26, 2017 at 8:14 AM, Jeevan Ladhe wrote: > I have rebased the patches on the latest commit. This needs another rebase. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

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

On Mon, Aug 14, 2017 at 7:51 AM, Jeevan Ladhe wrote: > I think even with this change there will be one level of indentation > needed for throwing the error, as the error is to be thrown only if > there exists a default partition. That's true, but we don't need two

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

Hi Robert, > 0005: > > Extend default partitioning support to allow addition of new partitions. > > + if (spec->is_default) > + { > + /* Default partition cannot be added if there already > exists one. */ > + if (partdesc->nparts > 0 && >

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

On Wed, Jul 12, 2017 at 3:31 PM, Jeevan Ladhe wrote: > 0001: > Refactoring existing ATExecAttachPartition code so that it can be used for > default partitioning as well Boring refactoring. Seems fine. > 0002: > This patch teaches the partitioning code to handle

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

On Sun, Jul 30, 2017 at 8:07 AM, Jeevan Ladhe wrote: > Hi Ashutosh, > > 0003 patch >> >> +parentRel = heap_open(parentOid, AccessExclusiveLock); >> In [2], Amit Langote has given a reason as to why heap_drop_with_catalog() >> should not heap_open() the

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

On Sat, Jul 29, 2017 at 2:55 AM, Robert Haas wrote: > On Fri, Jul 28, 2017 at 9:30 AM, Ashutosh Bapat > wrote: >> 0004 patch >> The patch adds another column partdefid to catalog pg_partitioned_table. The >> column gives OID of the default

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

Hi Ashutosh, 0003 patch > +parentRel = heap_open(parentOid, AccessExclusiveLock); > In [2], Amit Langote has given a reason as to why heap_drop_with_catalog() > should not heap_open() the parent relation. But this patch still calls > heap_open() without giving any counter argument. Also

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

On Fri, Jul 28, 2017 at 9:30 AM, Ashutosh Bapat wrote: > 0004 patch > The patch adds another column partdefid to catalog pg_partitioned_table. The > column gives OID of the default partition for a given partitioned table. This > means that the default partition's

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

On Wed, Jul 26, 2017 at 5:44 PM, Jeevan Ladhe wrote: > Hi, > > I have rebased the patches on the latest commit. > Thanks for rebasing the patches. The patches apply and compile cleanly. make check passes. Here are some review comments 0001 patch Most of this patch

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

Hello, On Thu, Jul 13, 2017 at 1:22 AM, Jeevan Ladhe wrote: > >> - Should probably be merged with the patch to add default partitioning >> for ranges. > > > Beena is already rebasing her patch on my latest patches, so I think getting > them merged here won't be an

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

Hi, I have tried to address your comments in the V22 set of patches[1]. Please find my feedback inlined on your comments. On Fri, Jun 16, 2017 at 1:46 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, I'd like to review this but it doesn't fit the master, as > Robert

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

Hi Ashutosh, I have tried to address your comments in the V22 set of patches[1]. Please find my feedback inlined on your comments. On Thu, Jun 15, 2017 at 10:24 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Some more comments on the latest set of patches. > > In

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

Hi Robert, I have tried to address your comments in the V22 set of patches[1]. Please find my feedback inlined on your comments. On Thu, Jun 15, 2017 at 1:21 AM, Robert Haas wrote: > > - Needs to be rebased over b08df9cab777427fdafe633ca7b8abf29817aa55. > Rebased on

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

On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita wrote: > So, I dropped the COPY part. Ouch. I think we should try to figure out how the COPY part will be handled before we commit to a design. I have to admit that I'm a little bit fuzzy about why foreign insert

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

On 2017/07/05 9:13, Amit Langote wrote: On 2017/06/29 20:20, Etsuro Fujita wrote: In relation to this, I also allowed expand_inherited_rtentry() to build an RTE and AppendRelInfo for each partition of a partitioned table that is an INSERT target, as mentioned by Amit in [1], by modifying

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

Fujita-san, On 2017/06/29 20:20, Etsuro Fujita wrote: > Hi, > > Here is a patch for $subject. This is based on Amit's original patch > (patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]). Thanks a lot for taking this up. > Main changes are: > > * I like Amit's idea that for

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

Hi, On Mon, Jun 19, 2017 at 12:34 PM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > On 2017/06/16 14:16, Ashutosh Bapat wrote: > > On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas > wrote: > >> On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat > >>

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

On Wed, Jun 21, 2017 at 8:47 PM, Amit Langote wrote: > It's the comma inside the error message that suggests to me that it's a > style that I haven't seen elsewhere in the backend code. Exactly. Avoid that. -- Robert Haas EnterpriseDB:

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

On 2017/06/21 21:37, Jeevan Ladhe wrote: > Hi Amit, > > On Thu, Jun 15, 2017 at 12:31 PM, Amit Langote < > langote_amit...@lab.ntt.co.jp> wrote: > >> Oops, I meant to send one more comment. >> >> On 2017/06/15 15:48, Amit Langote wrote: >>> BTW, I noticed the following in 0002 >> +

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

Thanks Ashutosh and Kyotaro for reviewing further. I shall address your comments in next version of my patch. Regards, Jeevan Ladhe On Fri, Jun 16, 2017 at 1:46 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, I'd like to review this but it doesn't fit the master, as >

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

Hi Amit, On Thu, Jun 15, 2017 at 12:31 PM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > Oops, I meant to send one more comment. > > On 2017/06/15 15:48, Amit Langote wrote: > > BTW, I noticed the following in 0002 > +errmsg("there exists a

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

Hi, Sorry for being away from here. I had some issues with my laptop, and I have resumed working on this. On Thu, Jun 15, 2017 at 1:21 AM, Robert Haas wrote: > On Wed, Jun 14, 2017 at 8:02 AM, Jeevan Ladhe > wrote: > > Here are the details

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

On 2017/06/16 14:16, Ashutosh Bapat wrote: > On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas wrote: >> On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat >> wrote: >>> Some more comments on the latest set of patches. >>> >>> In

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

Hello, I'd like to review this but it doesn't fit the master, as Robert said. Especially the interface of predicate_implied_by is changed by the suggested commit. Anyway I have some comment on this patch with fresh eyes. I believe the basic design so my comment below are from a rather micro

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

On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas wrote: > On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat > wrote: >> Some more comments on the latest set of patches. >> >> In heap_drop_with_catalog(), we heap_open() the parent table to get

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

On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat wrote: > Some more comments on the latest set of patches. > > In heap_drop_with_catalog(), we heap_open() the parent table to get the > default partition OID, if any. If the relcache doesn't have an entry for the >

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

Some more comments on the latest set of patches. In heap_drop_with_catalog(), we heap_open() the parent table to get the default partition OID, if any. If the relcache doesn't have an entry for the parent, this means that the entry will be created, only to be invalidated at the end of the

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

Oops, I meant to send one more comment. On 2017/06/15 15:48, Amit Langote wrote: > BTW, I noticed the following in 0002 +errmsg("there exists a default partition for table \"%s\", cannot add a new partition", This error message style seems novel to me.

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

On 2017/06/15 4:51, Robert Haas wrote: > On Wed, Jun 14, 2017 at 8:02 AM, Jeevan Ladhe > wrote: >> Here are the details of the patches in attached zip. >> 0001. refactoring existing ATExecAttachPartition code so that it can be >> used for >> default partitioning as

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

On Wed, Jun 14, 2017 at 8:02 AM, Jeevan Ladhe wrote: > Here are the details of the patches in attached zip. > 0001. refactoring existing ATExecAttachPartition code so that it can be > used for > default partitioning as well > 0002. support for default partition

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

While rebasing the current set of patches to the latest source, I realized that it might be a good idea to split the default partitioning support patch further into two incremental patches, where the first patch for default partition support would prevent addition of any new partition if there

Re: [HACKERS] ICU support on Windows

On Tue, Jun 13, 2017 at 6:45 PM, Peter Eisentraut wrote: > On 6/12/17 14:03, Ashutosh Sharma wrote: >>> I noticed that this only works if you use the "Win32" download of ICU, >>> because the "Win64" download uses "lib64" paths. I'm not sure what the >>> impact

  1   2   3   4   5   6   7   8   9   10   >