[HACKERS] Possible regression regarding estimating relation width in FDWs

Hello, While working on adapting the Multicorn FDW for 9.6, I noticed that there is a regression with regards to estimating the remote relation width. This behavior can be exposed using the postgres_fdw, using "use_remote_estimate". Test case: CREATE EXTENSION postgres_fdw; CREATE SERVER

Re: [HACKERS] Refactor pg_dump as a library?

Hello, Jakob. You wrote: JE> Would anybody else be interested in a pg_dump library? I've found JE> a thread from 2013 related to the idea, but the discussion came to nothing. JE> Thread started here: JE>

Re: [HACKERS] foreign table batch inserts

On 20 May 2016 at 08:47, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org [mailto: > pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > > Well, there's FE/BE level batching/pipelining already. Just no access to > it from libpq. >

[HACKERS] It's seems that the function "do_text_output_multiline" does not suit for format "line1\nline2\n...lineN".

Hi all, Today, I am do some works on adding some customized featues to PostgreSQL 9.6 beta1. But, when i do some output to psql using the fuction "do_text_output_multiline" with the string just like mentioned in mail tilte, such as "this is a\ntest for\nnew blank.". the PostgreSQL may lead to

Re: [HACKERS] Parallel safety tagging of extension functions

On Thu, May 19, 2016 at 05:50:01PM -0400, Andreas Karlsson wrote: > Hi, > > I have gone through all our extensions and tried to tag all functions > correctly according to their parallel safety. > > I also did the same for the aggregate functions in a second patch, and for >

Re: [HACKERS] Speedup twophase transactions

On Fri, May 20, 2016 at 12:46 PM, Alvaro Herrera wrote: > Jesper Pedersen wrote: >> Discussed with Noah off-list I think we should revisit this for 9.6 due to >> the async replica lag as shown in [1]. The performance improvement for the >> master node is shown in [2]. >

[HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

Old thread link: http://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com On Thu, Apr 14, 2016 at 1:29 PM, Stephen Frost wrote: > Jeff > > (Reviving an old thread for 2014...) > > Would you have time to work on this for 9.7..? I

Re: [HACKERS] Parallel safety tagging of extension functions

On 5/20/16 7:37 PM, Robert Haas wrote: I guess my first question is whether we have consensus on the release into which we should put this. Some people (Noah, among others) thought it should wait because we're after feature freeze, while others thought we should do it now. If we're going to

Re: [HACKERS] Parallel safety tagging of extension functions

On Fri, May 20, 2016 at 10:30 PM, Peter Eisentraut wrote: > On 5/20/16 7:37 PM, Robert Haas wrote: >> >> I guess my first question is whether we have consensus on the release >> into which we should put this. Some people (Noah, among others) >> thought it should

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

Just doing a drive-by... On Fri, May 20, 2016 at 3:50 PM, Jeff Davis wrote: > Old thread link: > > http://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com > > On Thu, Apr 14, 2016 at 1:29 PM, Stephen Frost

Re: [HACKERS] [PATCH] Add EXPLAIN (ALL) shorthand

On Thu, May 19, 2016 at 6:24 PM, Евгений Шишкин wrote: >> On 20 May 2016, at 01:12, Tom Lane wrote: >> I'm a bit inclined to think that what this is really about is that we >> made the wrong call on the BUFFERS option, and that it should default >> to ON

Re: [HACKERS] Parallel safety tagging of extension functions

On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson wrote: > I have gone through all our extensions and tried to tag all functions > correctly according to their parallel safety. > > I also did the same for the aggregate functions in a second patch, and for >

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian wrote: > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: >> 2) There's no ability at all to revert, other than restore a backup. That >> means if you pull the trigger and discover some major performance problem, >> you

Re: [HACKERS] what to revert

On Sun, May 15, 2016 at 4:06 PM, Tomas Vondra wrote: > Overall, I think this shows that there seems to be no performance penalty > with "disabled" vs. "reverted" - i.e. even with the least favorable (100% > read-only) workload. OK, that's good, as far as it goes. >

Re: [HACKERS] Declarative partitioning

Hi Amit, On 20.05.2016 11:37, Amit Langote wrote: Perhaps you're already aware but may I also suggest looking at how clauses are matched to indexes? For example, consider how match_clauses_to_index() in src/backend/optimizer/path/indxpath.c works. Thanks, I'll take a closer look at it.

Re: [HACKERS] foreign table batch inserts

On 20 May 2016 at 15:35, Craig Ringer wrote: > > You can, however, omit Sync from between messages and send a series of > protocol messages, like > > Parse/Bind/Execute/Bind/Execute/Bind/Execute/Sync > > to avoid round-trip overheads. > > I implemented what I think is a

Re: [HACKERS] It's seems that the function "do_text_output_multiline" does not suit for format "line1\nline2\n...lineN".

On 20 May 2016 at 19:13, Hao Lee wrote: > > Hi all, > > Today, I am do some works on adding some customized featues to PostgreSQL 9.6 > beta1. But, when i do some output to psql using the fuction > "do_text_output_multiline" with the string just like mentioned in mail tilte,

Re: [HACKERS] Speedup twophase transactions

Hi, On 04/13/2016 10:31 AM, Stas Kelvich wrote: On 13 Apr 2016, at 01:04, Michael Paquier wrote: That's too late for 9.6 unfortunately, don't forget to add that in the next CF! Fixed patch attached. There already was infrastructure to skip currently held locks

Re: [HACKERS] Speedup twophase transactions

Jesper Pedersen wrote: > Discussed with Noah off-list I think we should revisit this for 9.6 due to > the async replica lag as shown in [1]. The performance improvement for the > master node is shown in [2]. I gave a very quick look and it seems to me far more invasive than we would normally