Re: [HACKERS] multivariate statistics v14

2016-04-09 Thread Simon Riggs
On 8 April 2016 at 20:13, Tom Lane wrote: > I will make it a high priority for 9.7, though. > That is my plan also. I've already started reviewing the non-planner parts anyway, specifically patch 0002. -- Simon Riggshttp://www.2ndQuadrant.com/

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
I wrote: > Would it be possible to dial down the amount of runtime consumed by > the regression tests for this module? Hmm ... "perf" says that a full 50% of the runtime of contrib/bloom's regression test is consumed by GenericXLogFinish, and of that, the vast majority is consumed by the

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

2016-04-09 Thread Daniel Verite
Alvaro Herrera wrote: > I pushed it. That's awesome, thanks! Also thanks to Pavel who reviewed and helped continuously when iterating on this feature, and all others who participed in this thread. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
Teodor Sigaev writes: > Bloom index contrib module Would it be possible to dial down the amount of runtime consumed by the regression tests for this module? On my primary dev machine, "make installcheck" in contrib/bloom takes 4.5 seconds, which seems a bit excessive when make

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Alexander Korotkov
On Fri, Apr 8, 2016 at 10:19 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Fri, Apr 8, 2016 at 7:39 PM, Andres Freund wrote: > >> As you can see in >> > >>

Re: [HACKERS] closing CommitFest 2016-03, feature freeze now in effect

2016-04-09 Thread Stas Kelvich
> On 09 Apr 2016, at 03:05, Robert Haas wrote: > > CommitFest 2016-03 is now closed. I have moved "Twophase transactions > on slave", "Partial sort", and "amcheck (B-Tree integrity checking > tool)" to the next CommitFest in accordance with the policy previous > set by

Re: [HACKERS] VS 2015 support in src/tools/msvc

2016-04-09 Thread Michael Paquier
On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier wrote: > On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich > wrote: >> * Andrew Dunstan wrote: >>> On 04/08/2016 11:02 AM, Christian Ullrich wrote: src/port/chklocale.c(233): warning C4133:

Re: [HACKERS] closing CommitFest 2016-03, feature freeze now in effect

2016-04-09 Thread Robert Haas
On Sat, Apr 9, 2016 at 6:57 AM, Stas Kelvich wrote: > Aren’t "Twophase transactions on slave” falling into category of patches > that fixes > previously introduces behaviour? |'m not trying to argue with RMT decision, > but just > want to ensure that it was thoughtful

Re: [HACKERS] VS 2015 support in src/tools/msvc

2016-04-09 Thread Christian Ullrich
> Michael Paquier wrote: > > On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier > wrote: >> On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich >> wrote: >>> * Andrew Dunstan wrote: > On 04/08/2016 11:02 AM, Christian Ullrich wrote: >

Re: [HACKERS] Performance improvement for joins where outer side is unique

2016-04-09 Thread Robert Haas
On Thu, Apr 7, 2016 at 7:59 PM, Tom Lane wrote: > Anyway, I think it would be reasonable to give this patch a few more > days in view of David's being away through the weekend. But the RMT > has final say on that. The RMT has considered this request (sorry for the delay) and

Re: [HACKERS] multivariate statistics v14

2016-04-09 Thread Tomas Vondra
Hi, On 04/09/2016 01:21 AM, Tatsuo Ishii wrote: From: Tomas Vondra ... My feedback regarding docs were: - There's no docs for pg_mv_statistic (should be added to "49. System Catalogs") - The word "multivariate statistics" or something like that should

Re: [HACKERS] closing CommitFest 2016-03, feature freeze now in effect

2016-04-09 Thread Simon Riggs
On 9 April 2016 at 11:57, Stas Kelvich wrote: > > > On 09 Apr 2016, at 03:05, Robert Haas wrote: > > > > CommitFest 2016-03 is now closed. I have moved "Twophase transactions > > on slave", "Partial sort", and "amcheck (B-Tree integrity checking

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-04-09 Thread Pavel Stehule
Hi 2016-04-08 20:54 GMT+02:00 Pavel Stehule : > > > 2016-04-08 20:52 GMT+02:00 Tom Lane : > >> Pavel Stehule writes: >> > 2016-04-08 17:38 GMT+02:00 Teodor Sigaev : >> >> thank you, pushed. Pls, pay

Re: [HACKERS] Performance improvement for joins where outer side is unique

2016-04-09 Thread David Rowley
On 8 April 2016 at 02:46, Tom Lane wrote: > I'm also a bit suspicious of the fact that some of the plans in > aggregates.out changed from merge to hash joins; with basically > no stats at hand in those tests, that seems dubious. A quick look > at what the patch touched in

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Noah Misch
On Sat, Apr 09, 2016 at 11:50:08AM -0400, Tom Lane wrote: > Teodor Sigaev writes: > > Bloom index contrib module > > Would it be possible to dial down the amount of runtime consumed by > the regression tests for this module? > > On my primary dev machine, "make installcheck"

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Peter Geoghegan
On Sat, Apr 9, 2016 at 4:43 PM, Noah Misch wrote: > I find this added test duration reasonable. If someone identifies a way to > realize similar coverage with lower duration, I'd value that contribution. -1 > for meeting some runtime target at the expense of coverage. Older

[HACKERS] Some other things about contrib/bloom and generic_xlog.c

2016-04-09 Thread Tom Lane
1. It doesn't seem like generic_xlog.c has thought very carefully about the semantics of the "hole" between pd_lower and pd_upper. The mainline XLOG code goes to some lengths to ensure that the hole stays all-zeroes; for example RestoreBlockImage() explicitly zeroes the hole when restoring from a

Re: [HACKERS] Performance improvement for joins where outer side is unique

2016-04-09 Thread David Rowley
On 8 April 2016 at 11:59, Tom Lane wrote: > I did some performance testing on the attached somewhat-cleaned-up patch, > and convinced myself that the planning time penalty is fairly minimal: > on the order of a couple percent in simple one-join queries, and less > than that in

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Alexander Korotkov
On Sun, Apr 10, 2016 at 7:26 AM, Amit Kapila wrote: > On Sun, Apr 10, 2016 at 1:13 AM, Andres Freund wrote: > >> On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote: >> > There are results with 5364b357 reverted. >> >> > What exactly is this test?

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
I wrote: > I was depressed, though not entirely surprised, to find that you get > exactly that same line-count coverage if the table size is cut back > to ONE row. Oh, I found the flaw in my testing: there are two INSERTs in the test script and I was changing only one of them. After correcting

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Alexander Korotkov
On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund wrote: > > > On April 9, 2016 12:43:03 PM PDT, Andres Freund > wrote: > >On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote: > >> There are results with 5364b357 reverted. > > > >Crazy that this has such

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Amit Kapila
On Sun, Apr 10, 2016 at 1:13 AM, Andres Freund wrote: > On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote: > > There are results with 5364b357 reverted. > > What exactly is this test? I think assuming it is a read-only -M prepared pgbench run where data fits in shared

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
Noah Misch writes: > On Sat, Apr 09, 2016 at 11:50:08AM -0400, Tom Lane wrote: >> Would it be possible to dial down the amount of runtime consumed by >> the regression tests for this module? > I find this added test duration reasonable. If someone identifies a way to >

[HACKERS] tab completion for alter extension

2016-04-09 Thread Jeff Janes
tab completion for "alter extension foobar update" yields a list of tables. That is actively misleading. (This is not new in 9.6.) It should complete to nothing, or "TO" followed by a list of available versions. The attached patch takes approach 2. I thought of adding a ";" to the list

Re: [HACKERS] multivariate statistics v14

2016-04-09 Thread Tatsuo Ishii
> But I still think it wouldn't move the patch any closer to committable > state, because what it really needs is review whether the catalog > definition makes sense, whether it should be more like pg_statistic, > and so on. Only then it makes sense to describe the catalog structure > in the SGML

[HACKERS] GenericXLogUnregister seems like a pretty horrid idea

2016-04-09 Thread Tom Lane
I've been doing some code review in generic_xlog.c, and I find that GenericXLogUnregister is implemented in what seems to me to be a completely unsafe way: it shoves over the per-page array entries for following pages. The problem with that is that it invalidates the Page pointers previously

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-04-09 Thread Tom Lane
Pavel Stehule writes: > here is patch Pushed, thanks. regards, tom lane -- 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] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Alexander Korotkov
On Sat, Apr 9, 2016 at 11:24 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Fri, Apr 8, 2016 at 10:19 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> On Fri, Apr 8, 2016 at 7:39 PM, Andres Freund wrote: >> >>> As you can see in >>> >> >>>

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Andres Freund
On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote: > There are results with 5364b357 reverted. Crazy that this has such a negative impact. Amit, can you reproduce that? Alexander, I guess for r/w workload 5364b357 is a benefit on that machine as well? > It's much closer to what we had

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

2016-04-09 Thread Andres Freund
On April 9, 2016 12:43:03 PM PDT, Andres Freund wrote: >On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote: >> There are results with 5364b357 reverted. > >Crazy that this has such a negative impact. Amit, can you reproduce >that? Alexander, I guess for r/w workload

[HACKERS] Sort push down through a nested loop, for 9.7

2016-04-09 Thread Jeff Janes
I was testing to see if the newer changes in 9.6 fixed some planning issues I've seen in prior versions. It does not, for the ones of interest to me, but while looking into it I see what seems to be a missing optimization (in all versions). If the first child of a nested loop produces naturally

Re: [HACKERS] Combining Aggregates

2016-04-09 Thread David Rowley
On 9 April 2016 at 05:49, Robert Haas wrote: > On Fri, Apr 8, 2016 at 11:57 AM, Robert Haas wrote: >> On Wed, Apr 6, 2016 at 5:28 PM, David Rowley >> wrote: Is that everything now? I don't see anything about