Re: [HACKERS] proposal: schema variables

2018-08-22 9:00 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > AFAICR, I had an objection on such new objects when you first proposed >>> something similar in October 2016. >>> >>> Namely, if session variables are not transactional, they cannot be used >>> to >>> implement security related

Re: plan_cache_mode and postgresql.conf.sample

On Wed, Aug 22, 2018 at 03:41:26PM +0900, Michael Paquier wrote: > This line now spawns at 87 characters for me, so that's not quite it. I > think that you should just have put the list into two lines. Thanks Thomas for af63926, this addresses the issue. -- Michael signature.asc Description:

Re: Improve behavior of concurrent ANALYZE/VACUUM

On Wed, Aug 22, 2018 at 03:49:16PM +, Bossart, Nathan wrote: > I think so, since this is the only ownership checks we do on > individual partitions. Another simple way to test this would be to > create a partitioned table with a different owner than the partitions > and to run VACUUM as the

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-22 17:09:05 -0700, Andres Freund wrote: > Attached is a version doing so. Mildly updated version attached. This adds an explanatory commit message, removes one stray docs C89 reference, and fixes a mis-squashing of a patch. Greetings, Andres Freund >From

Re: Query is over 2x slower with jit=on

> On Aug 22, 2018, at 7:13 PM, Andres Freund wrote: > > On 2018-08-22 18:29:58 -0400, Jonathan S. Katz wrote: >> >>> On Aug 22, 2018, at 2:58 PM, Andreas Joseph Krogh >>> wrote: >>> >>> På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund >>> mailto:and...@anarazel.de>>: >>> On

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/08/22 21:30, David Rowley wrote: > On 22 August 2018 at 19:08, Amit Langote > wrote: >> +#define PartitionTupRoutingGetToParentMap(p, i) \ >> +#define PartitionTupRoutingGetToChildMap(p, i) \ >> >> If the "Get" could be replaced by "Child" and "Parent", respectively, >> they'd sound more

Re: Removing useless DISTINCT clauses

On 23 August 2018 at 08:11, Jim Finnerty wrote: > Here is an update to this thread, for potential inclusion in v12. I > couldn't get the most recent 'v5' patch to apply cleanly, so I recreated a > v6 patch on PG10.5 by hand, and made a few changes and improvements: Well, the patch I wrote was

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi, On 2018-08-22 20:16:24 -0400, Tom Lane wrote: > Andres Freund writes: > > There's a few further potential cleanups due to relying on c99: > > - Use __func__ unconditionally, rather than having configure test for it > > - Use inline unconditionally, rather than having configure test for it >

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Andres Freund writes: > There's a few further potential cleanups due to relying on c99: > - Use __func__ unconditionally, rather than having configure test for it > - Use inline unconditionally, rather than having configure test for it > - Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T, >

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi, On 2018-08-22 05:02:11 -0700, Andres Freund wrote: > If we agree on that, I'm going to propose a patch that includes: > - relevant cleanups to configure > - adapts sources.sgml to refer to C99 instead of C89 > - add some trivial conversions to for(int i;;) and struct initializers, > so the

Re: SPI_cursor_fetch Memory overrun

Wu Ivy writes: > fprintf(fp, (i == tupdesc->natts) ? "%s\n" : "%s," , > SPI_getvalue(tuple, tupdesc, i)); That (specifically the SPI_getvalue call) is what's leaking memory. You could improve matters by pfree'ing the result string after each such call. Just to add insult

Re: Query is over 2x slower with jit=on

On 2018-08-22 18:29:58 -0400, Jonathan S. Katz wrote: > > > On Aug 22, 2018, at 2:58 PM, Andreas Joseph Krogh > > wrote: > > > > På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund > > mailto:and...@anarazel.de>>: > > On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > > > I

SPI_cursor_fetch Memory overrun

Hi all, I’m creating a C extension to write data from the Postgres to a text file . Since the table can be very large, I only want to process one chunk of data per time to keep the memory stable. To achieve this, I use SPI

Re: JIT compiling with LLVM v12

Hi, On 2018-08-22 18:15:29 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-08-22 06:20:21 +, Noah Misch wrote: > >> Regardless of the choice of jit={on|off} default, these numbers tell me > >> that > >> some or all of jit_*_cost defaults are too low. > > > I don't think it really

Re: Query is over 2x slower with jit=on

> On Aug 22, 2018, at 2:58 PM, Andreas Joseph Krogh wrote: > > På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund > mailto:and...@anarazel.de>>: > On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > > I thought JITing of prepared queries happended once (in "prepare") > > No,

Re: JIT compiling with LLVM v12

Andres Freund writes: > On 2018-08-22 06:20:21 +, Noah Misch wrote: >> Regardless of the choice of jit={on|off} default, these numbers tell me that >> some or all of jit_*_cost defaults are too low. > I don't think it really shows that. The reason that JITing gets started > there is that the

Re: jsonpath

Attached 17th version of the patches rebased onto the current master. Nothing significant has changed. -- Nikita Glukhov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company sqljson_jsonpath_v17.tar.gz Description: application/gzip

Re: csv format for psql

Fabien COELHO wrote: > Doc: "according to the csv rules" -> "according to csv rules."? Fixed. > Doc: "RFC-4180" -> "RFC 4180"? Fixed. The other references to RFCs use this syntax indeed. > The previous RFC specifies CRLF as eol, but '\n' is hardcoded in the > source. I'm fine with

Re: Query is over 2x slower with jit=on

On 2018-08-22 20:48:48 +0200, Pierre Ducroquet wrote: > On Wednesday, August 22, 2018 6:51:55 PM CEST Andres Freund wrote: > > On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > > > Just to be clear; The query really runs slower (wall-clock time), it's not > > > just the timing. > > > >

Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund mailto:and...@anarazel.de>>: On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > I thought JITing of prepared queries happended once (in "prepare") No, it happens when the first JITed function is executed. >  so it didn't

Re: Query is over 2x slower with jit=on

On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > I thought JITing of prepared queries happended once (in "prepare") No, it happens when the first JITed function is executed. >  so it didn't have to do the JITing every time the query is > executed. Isn't the previously generated

Re: Query is over 2x slower with jit=on

On Wednesday, August 22, 2018 6:51:55 PM CEST Andres Freund wrote: > On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > > Just to be clear; The query really runs slower (wall-clock time), it's not > > just the timing. > > I bet it's not actually running slower, it "just" takes longer to

Re: Stored procedures and out parameters

On Wed, 22 Aug 2018 at 12:58, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 22/08/2018 18:49, David G. Johnston wrote: > > What others have done doesn't change the situation that has arisen for > > PostgreSQL due to its implementation history. > > What others have done seems

Sv: Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 18:51:55, skrev Andres Freund mailto:and...@anarazel.de>>: On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > Just to be clear; The query really runs slower (wall-clock time), it's not > just the timing. I bet it's not actually running slower, it "just"

Re: Stored procedures and out parameters

Peter>AFAICT in no case does it involve allowing functions to be called as procedures or vice versa. Oracle DB uses the same way to execute both procedures and functions: pl/sql block. For instance: procedure) begin my_proc(); end; function) begin :result := my_fun(); end; Call like begin

Re: Stored procedures and out parameters

On 22/08/2018 18:49, David G. Johnston wrote: > What others have done doesn't change the situation that has arisen for > PostgreSQL due to its implementation history. What others have done seems relevant, because the whole reason these questionable interfaces exist is to achieve compatibility

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 8/22/18 10:56 AM, Peter Eisentraut wrote: > On 22/08/2018 14:02, Andres Freund wrote: >> If we agree on that, I'm going to propose a patch that includes: >> - relevant cleanups to configure >> - adapts sources.sgml to refer to C99 instead of C89 >> - add some trivial conversions to for(int i;;)

Re: Query is over 2x slower with jit=on

On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > Just to be clear; The query really runs slower (wall-clock time), it's not > just the timing. I bet it's not actually running slower, it "just" takes longer to start up due to the JITing in each worker. I suspect what we should do is to

Re: Stored procedures and out parameters

On Wed, Aug 22, 2018 at 9:39 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 16/08/2018 19:54, Shay Rojansky wrote: > > I don't think there's anything really Microsoft-specific about any of > > this (except maybe in the history) - just like JDBC and psycopg, there's > >

Re: Stored procedures and out parameters

On 16/08/2018 19:54, Shay Rojansky wrote: > I don't think there's anything really Microsoft-specific about any of > this (except maybe in the history) - just like JDBC and psycopg, there's > simply a single standard way in the database API for invoking > server-side things, and not two ways. Have

Sv: Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 18:12:41, skrev Andres Freund mailto:and...@anarazel.de>>: Hi, On 2018-04-18 18:37:30 -0400, Robert Haas wrote: > On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: > > Not convinced that that is true - the issue is more likely that JIT work in workers is

Re: Query is over 2x slower with jit=on

> On Aug 22, 2018, at 12:12 PM, Andres Freund wrote: > > Hi, > > On 2018-04-18 18:37:30 -0400, Robert Haas wrote: >> On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: >>> Not convinced that that is true - the issue is more likely that JIT work in >>> workers is counted as execute time...

Re: JIT compiling with LLVM v12

On 22/08/2018 16:54, Andres Freund wrote: > I don't see particularly much benefit in deciding before beta, > personally. What's making you think it'd be important to decide before? > Pretty fundamentally, it'll be a setting you don't know is effectively > on, for the forseeable future anyway?

Re: Query is over 2x slower with jit=on

Hi, On 2018-04-18 18:37:30 -0400, Robert Haas wrote: > On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: > > Not convinced that that is true - the issue is more likely that JIT work in > > workers is counted as execute time... Gotta add that somehow, not sure what > > the best way would

Sv: Re: JIT compiling with LLVM v12

På onsdag 22. august 2018 kl. 16:36:00, skrev Peter Eisentraut < peter.eisentr...@2ndquadrant.com >: On 22/08/2018 08:20, Noah Misch wrote: > Regardless of the choice of jit={on|off} default, these numbers tell me that > some or all of jit_*_cost defaults

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi, On 2018-08-22 16:56:15 +0200, Peter Eisentraut wrote: > On 22/08/2018 14:02, Andres Freund wrote: > > - do we want to make declarations at arbitrary points errors? It's > > already a warning currently. > > While there are legitimate criticisms, it's a standard feature in C, > C++, and many

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 22/08/2018 14:02, Andres Freund wrote: > If we agree on that, I'm going to propose a patch that includes: > - relevant cleanups to configure > - adapts sources.sgml to refer to C99 instead of C89 > - add some trivial conversions to for(int i;;) and struct initializers, > so the relevant old

Re: JIT compiling with LLVM v12

Hi, On 2018-08-22 16:36:00 +0200, Peter Eisentraut wrote: > I'm suspicious that we haven't had much feedback about this. We've > heard of one or two cases where LLVM broke a query outright, and that > was fixed and that was a good result. But we haven't heard anything > about performance

Re: patch to allow disable of WAL recycling

On 2018-Aug-22, Andres Freund wrote: > On 2018-08-22 11:06:17 -0300, Alvaro Herrera wrote: > > I suppose that the use case that was initially proposed (ZFS) has not > > yet been tested so we shouldn't reject this patch immediately, but > > perhaps what Joyent people should be doing now is

Re: JIT compiling with LLVM v12

On 22/08/2018 08:20, Noah Misch wrote: > Regardless of the choice of jit={on|off} default, these numbers tell me that > some or all of jit_*_cost defaults are too low. That was also my earlier analysis. I'm suspicious that we haven't had much feedback about this. We've heard of one or two cases

Re: patch to allow disable of WAL recycling

On 2018-08-22 11:06:17 -0300, Alvaro Herrera wrote: > On 2018-Aug-21, Jerry Jelinek wrote: > > > Tomas, > > > > Thanks for doing all of this testing. Your testing and results are much > > more detailed than anything I did. Please let me know if there is any > > follow-up that I should attempt. >

Re: patch to allow disable of WAL recycling

On 2018-Aug-21, Jerry Jelinek wrote: > Tomas, > > Thanks for doing all of this testing. Your testing and results are much > more detailed than anything I did. Please let me know if there is any > follow-up that I should attempt. Either I completely misread these charts, or there is practically

Re: Pre-v11 appearances of the word "procedure" in v11 docs

> On Aug 22, 2018, at 9:15 AM, Peter Eisentraut > wrote: > > On 18/08/2018 19:37, Jonathan S. Katz wrote: >> I reviewed the patches, here are my comments. > > Committed all three with some adjustments. Thanks. Awesome, thanks! I removed the open item. Jonathan signature.asc Description:

Re: Pre-v11 appearances of the word "procedure" in v11 docs

On 18/08/2018 19:37, Jonathan S. Katz wrote: > I reviewed the patches, here are my comments. Committed all three with some adjustments. Thanks. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: plan_cache_mode and postgresql.conf.sample

On 22 August 2018 at 18:41, Michael Paquier wrote: > On Wed, Aug 22, 2018 at 06:26:52PM +1200, Thomas Munro wrote: >> Thanks, pushed. I removed one tab because it looks like the comments >> in that file are supposed to line up with tabstop=8 (unlike our source >> files which use 4), and this one

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 22 August 2018 at 19:08, Amit Langote wrote: > +#define PartitionTupRoutingGetToParentMap(p, i) \ > +#define PartitionTupRoutingGetToChildMap(p, i) \ > > If the "Get" could be replaced by "Child" and "Parent", respectively, > they'd sound more meaningful, imho. I did that to save 3 chars. I

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Wed, Aug 22, 2018 at 5:32 PM, Andres Freund wrote: > Hi, > > On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote: > > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 > R2. > > For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use > > 2013. For v11, we

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi, On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote: > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2. > For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use > 2013. For v11, we use 2017. Sndeep: Thanks for the information. Did you ever

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Wed, Aug 22, 2018 at 4:59 AM, Andres Freund wrote: > On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote: > > > > > > On 08/21/2018 04:49 PM, Andres Freund wrote: > > > On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote: > > > > On 08/21/2018 11:06 AM, Andrew Dunstan wrote: > > > > > > > > >

Re: C99 compliance for src/port/snprintf.c

Hi On Thu, Aug 16, 2018 at 6:30 PM, Andres Freund wrote: > Hi, > > On 2018-08-16 14:28:25 +0200, Peter Eisentraut wrote: > > On 16/08/2018 01:06, Andres Freund wrote: > > > So it looks like msvc 2013 might be the relevant requirement. > > > > According to my research (completely untested in

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/08/16 12:00), Etsuro Fujita wrote: (2018/08/15 23:40), Robert Haas wrote: Given the comments from the RMT, and also on general principle, it seems like we really need to get on with committing something here. It's my understanding you plan to do that, since it's your patch. When? I plan

Re: Proposal: SLRU to Buffer Cache

Hi, On 2018-08-22 13:35:47 +0500, Andrey Borodin wrote: > > 15 авг. 2018 г., в 2:35, Shawn Debnath написал(а): > > > > At the Unconference in Ottawa this year, I pitched the idea of moving > > components off of SLRU and on to the buffer cache. The motivation > > behind the idea was three fold:

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Tue, Aug 21, 2018 at 11:16 PM, Tom Lane wrote: > Andres Freund writes: >> On 2018-08-21 13:29:20 -0400, Tom Lane wrote: >>> We've got a buildfarm handy that could answer the question. >>> Let's just stick a test function in there for a day and see >>> which animals fail. > >> I think we

Re: Two proposed modifications to the PostgreSQL FDW

On Wed, Aug 22, 2018 at 5:13 PM Chris Travers wrote: > > > > On Wed, Aug 22, 2018 at 9:09 AM Masahiko Sawada wrote: >> >> On Wed, Aug 22, 2018 at 1:20 PM Chris Travers >> wrote: >> > The two things I would suggest is that rather than auto-detecting (if I >> > understand your patch correctly)

Re: Proposal: SLRU to Buffer Cache

Hi! > 15 авг. 2018 г., в 2:35, Shawn Debnath написал(а): > > At the Unconference in Ottawa this year, I pitched the idea of moving > components off of SLRU and on to the buffer cache. The motivation > behind the idea was three fold: > > * Improve performance by eliminating fixed sized caches,

Re: JIT compiling with LLVM v12

On 2018-08-22 06:20:21 +, Noah Misch wrote: > On Wed, Mar 28, 2018 at 02:27:51PM -0700, Andres Freund wrote: > > For now LLVM is enabled by default when compiled --with-llvm. I'm mildly > > inclined to leave it like that until shortly before the release, and > > then disable it by default

Re: Two proposed modifications to the PostgreSQL FDW

On Wed, Aug 22, 2018 at 9:09 AM Masahiko Sawada wrote: > On Wed, Aug 22, 2018 at 1:20 PM Chris Travers > wrote: > > The two things I would suggest is that rather than auto-detecting (if I > understand your patch correctly) whether prepared transactions are possible > on the other system, making

Re: Two proposed modifications to the PostgreSQL FDW

On Wed, Aug 22, 2018 at 1:20 PM Chris Travers wrote: > > > > On Wed, Aug 22, 2018 at 3:12 AM Masahiko Sawada wrote: >> >> On Tue, Aug 21, 2018 at 5:36 PM Chris Travers >> wrote: >> > >> > >> > >> > On Tue, Aug 21, 2018 at 8:42 AM Masahiko Sawada >> > wrote: >> >> >> >> On Tue, Aug 21, 2018

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/08/21 14:44, David Rowley wrote: > On 3 August 2018 at 17:58, Amit Langote wrote: >> On 2018/07/31 16:03, David Rowley wrote: >>> Maybe we can do that as a follow-on patch. >> >> We probably could, but I think it would be a good idea get rid of *all* >> redundant allocations due to tuple

Re: [HACKERS] proposal: schema variables

Hello Pavel, AFAICR, I had an objection on such new objects when you first proposed something similar in October 2016. Namely, if session variables are not transactional, they cannot be used to implement security related auditing features which were advertised as the motivating use case: an

Re: plan_cache_mode and postgresql.conf.sample

On Wed, Aug 22, 2018 at 06:26:52PM +1200, Thomas Munro wrote: > Thanks, pushed. I removed one tab because it looks like the comments > in that file are supposed to line up with tabstop=8 (unlike our source > files which use 4), and this one didn't. I hope I got that right! This line now spawns

Re: plan_cache_mode and postgresql.conf.sample

On Wed, Aug 22, 2018 at 5:45 PM, David Rowley wrote: > While testing something that I needed to ensure a generic plan was > being used, during editing postgresql.conf I couldn't quite remember > the exact spelling of the option to do that. I think the valid > options for the setting should be

Re: JIT compiling with LLVM v12

On Wed, Mar 28, 2018 at 02:27:51PM -0700, Andres Freund wrote: > For now LLVM is enabled by default when compiled --with-llvm. I'm mildly > inclined to leave it like that until shortly before the release, and > then disable it by default (i.e. change the default of jit=off). But I > think we can