Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

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] Move PinBuffer and UnpinBuffer to atomics

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

[HACKERS] tab completion for alter extension

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

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

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] Move PinBuffer and UnpinBuffer to atomics

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] Performance improvement for joins where outer side is unique

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] Performance improvement for joins where outer side is unique

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

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] [COMMITTERS] pgsql: Bloom index contrib module

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 >

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

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

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

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] proposal: PL/Pythonu - function ereport

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] proposal: PL/Pythonu - function ereport

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

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

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] Move PinBuffer and UnpinBuffer to atomics

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

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

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

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 >>> >> >>>

[HACKERS] GenericXLogUnregister seems like a pretty horrid idea

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] multivariate statistics v14

> 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

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

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] [COMMITTERS] pgsql: Bloom index contrib module

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] [patch] Proposal for \crosstabview in psql

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] VS 2015 support in src/tools/msvc

> 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] VS 2015 support in src/tools/msvc

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

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] multivariate statistics v14

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] Performance improvement for joins where outer side is unique

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] closing CommitFest 2016-03, feature freeze now in effect

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] closing CommitFest 2016-03, feature freeze now in effect

> 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] Combining Aggregates

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

Re: [HACKERS] multivariate statistics v14

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] Move PinBuffer and UnpinBuffer to atomics

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 >> > >>