Re: [HACKERS] Perf Benchmarking and regression.

Hi, Please find the results for the following 3 scenarios with unpatched master: 1. Default settings for *_flush_after : TPS = *10677.662356* 2. backend_flush_after=0, rest defaults : TPS = *18452.655936* 3. backend_flush_after=0, bgwriter_flush_after=0, wal_writer_flush_after=0,

Re: [HACKERS] 10.0

+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc. It will hopefully both end these discussions and remove the confusion the current versioning scheme has (I too heard way to many times about people using postgres8 or postgres9). For those saying this is version inflation. I don't

Re: [HACKERS] 10.0

El 13/05/16 a las 15:36, Josh berkus escribió: > On 05/13/2016 11:31 AM, Alvaro Herrera wrote: >> Josh berkus wrote: >> >>> Anyway, can we come up with a consensus of some minimum changes it will >>> take to make the next version 10.0? >> >> I think the next version should be 10.0 no matter what

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 11:39 AM, Tom Lane wrote: > Robert Haas writes: >> There is a long-running thread on pgsql-hackers on whether 9.6 should >> instead be called 10.0. > > First I've seen it mentioned here. > > I think you are just about exactly one

Re: [HACKERS] 10.0

El 13/05/16 a las 15:31, Alvaro Herrera escribió: > Josh berkus wrote: > >> Anyway, can we come up with a consensus of some minimum changes it will >> take to make the next version 10.0? > > I think the next version should be 10.0 no matter what changes we put > in. +1 And another +1 on Tom's

Re: [HACKERS] Perf Benchmarking and regression.

Hello, Please find the results for the following 3 scenarios with unpatched master: 1. Default settings for *_flush_after : TPS = *10677.662356* 2. backend_flush_after=0, rest defaults : TPS = *18452.655936* 3. backend_flush_after=0, bgwriter_flush_after=0, wal_writer_flush_after=0,

Re: [HACKERS] Just-in-time compiling things

On 05/14/2016 12:10 PM, Andreas Seltenreich wrote: Konstantin Knizhnik writes: Latest information from ISP RAS guys: them have made good progress since February: them have rewritten most of methods of Scan, Aggregate and Join to LLVM API. Is their work available somewhere? I'm experimenting

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Tue, Mar 22, 2016 at 12:56 AM, Amit Kapila wrote: >> >> Yes, same random number generation is not the problem. In windows apart >> >> from EEXIST error, EACCES also needs to be validated and returned for >> >> new random number generation, instead of throwing an error.

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Mon, May 9, 2016 at 3:17 AM, Michael Paquier wrote: > On Tue, Mar 22, 2016 at 1:56 PM, Amit Kapila wrote: >> So as far as I can see there are two ways to resolve this issue, one is to >> retry generation of dsm name if CreateFileMapping

Re: [HACKERS] 10.0

On 05/14/2016 07:08 AM, Robert Haas wrote: On Fri, May 13, 2016 at 8:00 PM, Tom Lane wrote: Any project that starts inflating its numbering scheme sends a message to users of the form, "hey, we've just been taken over by marketing people, and software quality will go down

Re: [HACKERS] Losing memory references - SRF + SPI

On 05/13/2016 09:35 PM, Anderson Carniel wrote: > I am writing a function that returns a set of tuples by using also the > PostGIS. Thuis, I am using SRF too. It successfully returns the expected > result when it has at most 4 tuples. However, this is not the case when > more than 4 tuples have to

[HACKERS] exit() behavior on Windows?

Rather belatedly, I've started to look into a fix for pg_dump's problem with error reporting in parallel mode: http://www.postgresql.org/message-id/2458.1450894...@sss.pgh.pa.us One of the issues here is that pg_dump uses threads not subprocesses to do parallelism on Windows, which means that

Re: [HACKERS] 10.0

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Wasn't there some controversy about switching to major.minor versioning > this in -advocacy? > > http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com I proposed in that thread that we always increment the first

Re: [HACKERS] 10.0

"Greg Sabino Mullane" writes: > I think moving to a two-number format is a mistake: what exactly will > PQserverVersion() return in that case? For, say, 10.2 it would be 12, equivalent to 10.0.2 under old style. We could redefine it as being major plus four-digit minor,

Re: [HACKERS] 10.0

On Sat, May 14, 2016 at 7:51 PM, Greg Sabino Mullane wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > >> Wasn't there some controversy about switching to major.minor versioning >> this in -advocacy? >> >>

Re: [HACKERS] Losing memory references - SRF + SPI

Thank you very much Joe. I have followed the crosstab() implementation and understood the idea of per query memory context. Now, I am using a unique SPI instance (which I perform several sql queries), process the result, transform my result into a tuplestore, close the SPI and done. It works

Re: [HACKERS] 10.0

Jeff Janes writes: > There are lots of improvement which get done to in-memory data > structures that wouldn't require a pg_dump/pg_upgrade, which could in > principle be ported into prior major versions if we had the resources > (reviewing, testing, packaging) to do it,

Re: [HACKERS] Perf Benchmarking and regression.

These raw tps suggest that {backend,bgwriter}_flush_after should better be zero for this kind of load.Whether it should be the default is unclear yet, because as Andres pointed out this is one kind of load. FWIW, I don't think {backend,bgwriter} are the same here. It's primarily backend that

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote: > The underlying premise, for me, of choosing .4 or .5 was that presently we > discontinue support after 5 years/releases. A new .0 would come out just > as we discontinue the previous .0 Well maybe the 5 year support cycle

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 08:55:20PM -0400, David G. Johnston wrote: > The opinion seems to be that major.0 is some kind of magic incantation in > the broader world of users... >From my reading of the thread, while certainly that is the general definition of a .0, having infrequent .0 releases is

Re: [HACKERS] 10.0

On 05/13/2016 07:18 PM, Mark Dilger wrote: > My main concern is that a commitment to never, ever break backwards > compatibility is a commitment to obsolescence. It therefore makes sense to > reserve room in the numbering scheme to be clear and honest about when > backwards compatibility has been

Re: [HACKERS] exit() behavior on Windows?

I wrote: > If it's just a quick kill, then there's a totally separate bug here for > Windows. What is likely to happen with the current coding is that a > failing child thread will queue its error message into the communication > pipe, and then exit(1), thereby killing the whole pg_dump process

Re: [HACKERS] 10.0

On 14/05/16 02:00, Tom Lane wrote: [...] I don't think this is about version number inflation, but actually more the opposite. What you're calling the major number is really a marketing number. There is not a technical distinction between major releases where we choose to bump the first

[HACKERS] Just-in-time compiling things (was: asynchronous and vectorized execution)

Konstantin Knizhnik writes: > Latest information from ISP RAS guys: them have made good progress > since February: them have rewritten most of methods of Scan, Aggregate > and Join to LLVM API. Is their work available somewhere? I'm experimenting in that area as well, although I'm using libFirm

Re: [HACKERS] 10.0

Re: Álvaro Hernández Tortosa 2016-05-14 <5736f966.3040...@8kdata.com> > Having said that, I believe having a single major number is a more > effective marketing. Non major-major versions may make the release look like > a "probably not worth" upgrade. People may hold their breath until a >

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 8:00 PM, Tom Lane wrote: >> Any project that starts inflating its numbering scheme sends a message to >> users of the form, "hey, we've just been taken over by marketing people, and >> software quality will go down from now on." > > I don't think this

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-05-14 18:49:27 +0200, Fabien COELHO wrote: > > Hello, > > > Please find the results for the following 3 scenarios with unpatched master: > > > > 1. Default settings for *_flush_after : TPS = *10677.662356* > > 2. backend_flush_after=0, rest defaults : TPS = *18452.655936* > > 3.

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

[ getting back to a complaint I made in December ] I wrote: > ... the pg_dump process has crashed with a SIGPIPE without printing > any message whatsoever, and without coming anywhere near finishing the > dump. > A bit of investigation says that this is because somebody had the bright > idea