Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hello, How did this testing turn out? Palle 3 jul 2014 kl. 12:15 skrev Tatsuo Ishii : > Hi, > >> Hi, >> >> Attached you can find a short (compile tested only ) patch implementing >> a 'shared_memory_type' GUC, akin to 'dynamic_shared_memory_type'. Will >> only apply to 9.4, not 9.3, but it sh

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, > Hi, > > Attached you can find a short (compile tested only ) patch implementing > a 'shared_memory_type' GUC, akin to 'dynamic_shared_memory_type'. Will > only apply to 9.4, not 9.3, but it should be easy to convert for it. > > Greetings, > > Andres Freund I have rebased Andres's patch a

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: > JFYI we have 3 or 4 machines racked for the pgsql project in our DC. Oh, great! > Tom informed me he would be lighting them up this week time permitting. Excellent, many thanks! Stephen signature.asc Description: Digital sig

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

JFYI we have 3 or 4 machines racked for the pgsql project in our DC. Tom informed me he would be lighting them up this week time permitting. Sent from my iPhone > On Apr 26, 2014, at 6:15 PM, Stephen Frost wrote: > > Jim, > > * Jim Nasby (j...@nasby.net) wrote: >>> On 4/22/14, 5:01 PM, Alf

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Jim, * Jim Nasby (j...@nasby.net) wrote: > On 4/22/14, 5:01 PM, Alfred Perlstein wrote: > >We also have colo space and power, etc. So this would be the whole deal. > >The cluster would be up for as long as needed. > > > >Are the machine specs sufficient? Any other things we should look for? >

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/22/14, 5:01 PM, Alfred Perlstein wrote: Hey folks, I just spoke with our director of netops Tom Sparks here at Norse and we have a vested interest in Postgresql. We can throw together a cluster of 4 machines with specs approximately in the range of dual quad core westmere with ~64GB of

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 24/04/14 09:26, Tatsuo Ishii wrote: > Included is the graph (from PostgreSQL Enterprise Consortium's 2014 > report page 13: https://www.pgecons.org/downloads/43). I see up to 14% > degration (at 128 concurrent users) comparing with 9.2. That URL returns 'Forbidden'... >>> >

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 11:25:35PM +0200, Andres Freund wrote: > On 2014-04-21 17:21:20 -0400, Bruce Momjian wrote: > > On Mon, Apr 21, 2014 at 02:08:51PM -0700, Joshua Drake wrote: > > > If the community had more *BSD presence I think it would be great > > > but it isn't all that viable at this po

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> On Apr 22, 2014, at 5:07 PM, Andrew Dunstan wrote: > > >> On 04/22/2014 06:43 PM, Mark Wong wrote: >> On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake > > wrote: >> >> >>On 04/22/2014 08:26 AM, Andrew Dunstan wrote: >> >>I'm going away tomorrow fo

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

>> >> Included is the graph (from PostgreSQL Enterprise Consortium's 2014 >> >> report page 13: https://www.pgecons.org/downloads/43). I see up to 14% >> >> degration (at 128 concurrent users) comparing with 9.2. >> > >> > That URL returns 'Forbidden'... >> >> Sorry for this. I sent a problem repor

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> - NetBSD: crashes under load; this could have been fixed but when I ran the > benchmarks in 2012 none of the developers seemed to care. do you mean this? https://mail-index.netbsd.org/tech-kern/2012/08/29/msg013918.html YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 23/04/14 00:19, Andres Freund wrote: Hi, Attached you can find a short (compile tested only ) patch implementing a 'shared_memory_type' GUC, akin to 'dynamic_shared_memory_type'. Will only apply to 9.4, not 9.3, but it should be easy to convert for it. Have just tried this out (on Ubuntu 1

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/22/2014 06:43 PM, Mark Wong wrote: On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake mailto:j...@commandprompt.com>> wrote: On 04/22/2014 08:26 AM, Andrew Dunstan wrote: I'm going away tomorrow for a few days R&R. when I'm back next week I will set up a demo

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake wrote: > > On 04/22/2014 08:26 AM, Andrew Dunstan wrote: > > I'm going away tomorrow for a few days R&R. when I'm back next week I >> will set up a demo client running this module. If you can have a machine >> prepped for this purpose by then so m

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/22/14, 8:26 AM, Andrew Dunstan wrote: On 04/22/2014 01:36 AM, Joshua D. Drake wrote: On 04/21/2014 06:19 PM, Andrew Dunstan wrote: If we never start we'll never get there. I can think of several organizations that might be approached to donate hardware. Like .Org? We have a hardwa

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 8:06 PM, Andrew Dunstan wrote: > > On 04/21/2014 08:49 PM, Stephen Frost wrote: >> >> * Tatsuo Ishii (is...@postgresql.org) wrote: >>> >>> I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux >>> as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/22/2014 08:26 AM, Andrew Dunstan wrote: I'm going away tomorrow for a few days R&R. when I'm back next week I will set up a demo client running this module. If you can have a machine prepped for this purpose by then so much the better, otherwise I will have to drag out a box I recently re

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

22 apr 2014 kl. 17:26 skrev Andrew Dunstan : > > On 04/22/2014 01:36 AM, Joshua D. Drake wrote: >> >> On 04/21/2014 06:19 PM, Andrew Dunstan wrote: >> >>> >>> If we never start we'll never get there. >>> >>> I can think of several organizations that might be approached to donate >>> hardware

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/22/2014 01:36 AM, Joshua D. Drake wrote: On 04/21/2014 06:19 PM, Andrew Dunstan wrote: If we never start we'll never get there. I can think of several organizations that might be approached to donate hardware. Like .Org? We have a hardware farm, a rack full of hardware and spindles

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

* Magnus Hagander (mag...@hagander.net) wrote: > I didn't realize we had a guc for dynamic shared memory, must've missed > that in the discussion about that one. I agree that if we have that, it > makes perfect sense to have the same setting available for the main shared > memory segment. I recall

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Tue, Apr 22, 2014 at 8:26 AM, Mark Kirkwood < mark.kirkw...@catalyst.net.nz> wrote: > On 22/04/14 09:25, Andres Freund wrote: > >> On 2014-04-21 17:21:20 -0400, Bruce Momjian wrote: >> >>> On Mon, Apr 21, 2014 at 02:08:51PM -0700, Joshua Drake wrote: >>> If the community had more *BSD pres

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, Attached you can find a short (compile tested only ) patch implementing a 'shared_memory_type' GUC, akin to 'dynamic_shared_memory_type'. Will only apply to 9.4, not 9.3, but it should be easy to convert for it. Greetings, Andres Freund -- Andres Freund http://www.2ndQ

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 22/04/14 09:25, Andres Freund wrote: On 2014-04-21 17:21:20 -0400, Bruce Momjian wrote: On Mon, Apr 21, 2014 at 02:08:51PM -0700, Joshua Drake wrote: If the community had more *BSD presence I think it would be great but it isn't all that viable at this point. I do know however that no-one in

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Tue, Apr 22, 2014 at 9:58 AM, Tatsuo Ishii wrote: > > * Tatsuo Ishii (is...@postgresql.org) wrote: > >> I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux > >> as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL 6, > >> pgbench is used (read only query), scale fact

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

>> Can you isolate the sysv-vs-mmap patch and see what happens with just >> that change..? > > Unfortunately I don't have an access to the machine at this moment. Where is the patch? I would like to test it on a smaller machine for now. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 06:19 PM, Andrew Dunstan wrote: If we never start we'll never get there. I can think of several organizations that might be approached to donate hardware. Like .Org? We have a hardware farm, a rack full of hardware and spindles. It isn't the most current but it is there. S

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 09:16 PM, Peter Geoghegan wrote: On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii wrote: What we would need is a way to graph the results - that's something beyond my very rudimentary expertise in web programming. If anyone feels like collaborating I'd be glad to hear from them (The

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii wrote: >> What we would need is a way to graph the results - that's something >> beyond my very rudimentary expertise in web programming. If anyone >> feels like collaborating I'd be glad to hear from them (The web site >> is programmed in perl + Templ

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> This is exactly why we need a benchfarm. > > I actually have a client working based on Greg Smith's pgbench tools. > > What we would need is a way to graph the results - that's something > beyond my very rudimentary expertise in web programming. If anyone > feels like collaborating I'd be glad

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 08:49 PM, Stephen Frost wrote: * Tatsuo Ishii (is...@postgresql.org) wrote: I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL 6, pgbench is used (read only query), scale factor is 1,000 (DB size 15GB

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> * Tatsuo Ishii (is...@postgresql.org) wrote: >> I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux >> as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL 6, >> pgbench is used (read only query), scale factor is 1,000 (DB size >> 15GB). > > Can you isolate the sysv-vs

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

* Tatsuo Ishii (is...@postgresql.org) wrote: > I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux > as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL 6, > pgbench is used (read only query), scale factor is 1,000 (DB size > 15GB). Can you isolate the sysv-vs-mmap patc

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 03:08 PM, Jim Nasby wrote: On 4/21/14, 4:08 PM, Joshua D. Drake wrote: If the community had more *BSD presence I think it would be great but it isn't all that viable at this point. I do know however that no-one in this community would turn down a team of FreeBSD advocates helping

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 4:10 AM, Andres Freund wrote: > If there are indeed such large regressions on FreeBSD we need to treat > them as postgres regressions. It's nicer not to add config options for > things that don't need it, but apparently that's not the case here. +1, but I think this is som

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm > wondering who to poke to mitigate the problem. In reference to this thread > [1], who where the FreeBSD people that Francois mentioned? If mmap needs to > perform well in the kernel, I'd like to know of someone with

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Stephen Frost wrote > * Alfred Perlstein ( > alfred@ > ) wrote: >> On 4/21/14, 12:47 PM, Stephen Frost wrote: >> > Asking for help to address the FreeBSD performance would have >> >been much better received. Thanks, Stephen >> >> That is exactly what I did, I asked for a version of postgresql t

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 4:08 PM, Joshua D. Drake wrote: If the community had more *BSD presence I think it would be great but it isn't all that viable at this point. I do know however that no-one in this community would turn down a team of FreeBSD advocates helping us make PostgreSQL awesome for PostgreSQ

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 2:23 PM, Stephen Frost wrote: Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: On 4/21/14, 12:47 PM, Stephen Frost wrote: Asking for help to address the FreeBSD performance would have been much better received. Thanks, Stephen That is exactly what I did, I asked for a ver

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 2014-04-21 17:21:20 -0400, Bruce Momjian wrote: > On Mon, Apr 21, 2014 at 02:08:51PM -0700, Joshua Drake wrote: > > If the community had more *BSD presence I think it would be great > > but it isn't all that viable at this point. I do know however that > > no-one in this community would turn dow

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 02:08:51PM -0700, Joshua Drake wrote: > If the community had more *BSD presence I think it would be great > but it isn't all that viable at this point. I do know however that > no-one in this community would turn down a team of FreeBSD advocates > helping us make PostgreSQL

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: > On 4/21/14, 12:47 PM, Stephen Frost wrote: > > Asking for help to address the FreeBSD performance would have > >been much better received. Thanks, Stephen > > That is exactly what I did, I asked for a version of postgresql that > was easy

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 10:39 AM, Alfred Perlstein wrote: What I am seeing here is unfortunately a very strong departure from FreeBSD support by the community from several of the developers. In fact over drinks at pgcon last year there were a TON of jokes making fun of FreeBSD users and developers which

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 01:52:48PM -0700, Alfred Perlstein wrote: > > On 4/21/14, 12:47 PM, Stephen Frost wrote: > > Asking for help to address the FreeBSD performance would have > >been much better received. Thanks, Stephen > > That is exactly what I did, I asked for a version of postgresql tha

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 12:47 PM, Stephen Frost wrote: Asking for help to address the FreeBSD performance would have been much better received. Thanks, Stephen That is exactly what I did, I asked for a version of postgresql that was easy to switch at runtime between two behaviors. That would make it

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

* Andres Freund (and...@2ndquadrant.com) wrote: > On 2014-04-21 15:47:31 -0400, Stephen Frost wrote: > > That's certainly unfortunate. For my 2c, I'd recommend that you write a > > minimal implementation that allows you to test just the sysv-vs-mmap > > case (which could certainly take an option,

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 2014-04-21 15:47:31 -0400, Stephen Frost wrote: > That's certainly unfortunate. For my 2c, I'd recommend that you write a > minimal implementation that allows you to test just the sysv-vs-mmap > case (which could certainly take an option, to avoid having to > recompile during testing), or even

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: > Stephen, please calm down on the hyperbole, seriously, picking > another db is not an attack. Perhaps it wasn't intended by you, but to those of us reading it, your comments came across clearly as "if you don't fix this, then we won't use P

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 11:14 AM, Stephen Frost wrote: Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: On 4/21/14, 9:51 AM, Andres Freund wrote: On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote: Sure, to be fair, we are under the gun here for a product, it may just mean that the end result of

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: > On 4/21/14, 9:51 AM, Andres Freund wrote: > >On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote: > >>Sure, to be fair, we are under the gun here for a product, it may just mean > >>that the end result of that conversation is "mysql". > >Pe

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 9:52 AM, Alvaro Herrera wrote: Alfred Perlstein wrote: I am unsure of the true overhead of making this a runtime tunable so pardon if I'm asking for "a lot". From the perspective of both an OS developer and postgresql user (I am both) it really makes more sense to have it a runtim

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

* Alfred Perlstein (alf...@freebsd.org) wrote: > How high on the hierarchy of PostgreSQL's "needs" is making a single > option a tunable versus compile time thing? I mean seriously you > mean to stick on this one point when one of your users are asking > you about this? That is pretty concerning

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 9:51 AM, Andres Freund wrote: On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote: Sure, to be fair, we are under the gun here for a product, it may just mean that the end result of that conversation is "mysql". Personally arguments in that vain are removing just about any incenti

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Alfred Perlstein wrote: > How high on the hierarchy of PostgreSQL's "needs" is making a single > option a tunable versus compile time thing? I mean seriously you > mean to stick on this one point when one of your users are asking > you about this? That is pretty concerning to me. I think the s

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 9:51 AM, Andrew Dunstan wrote: On 04/21/2014 12:44 PM, Alfred Perlstein wrote: On 4/21/14 9:38 AM, Andrew Dunstan wrote: On 04/21/2014 12:25 PM, Alfred Perlstein wrote: 1. OS developers are not the target audience for GUCs. If the OS developers want to test and can't be bo

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 4:10 AM, Andres Freund wrote: Hi, On 2014-04-20 11:24:38 +0200, Palle Girgensohn wrote: I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm wondering who to poke to mitigate the problem. In reference to this thread [1], who where the FreeBSD people that Fra

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Alfred Perlstein wrote: > I am unsure of the true overhead of making this a runtime tunable so > pardon if I'm asking for "a lot". From the perspective of both an > OS developer and postgresql user (I am both) it really makes more > sense to have it a runtime tunable for the following reasons: >

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote: > Sure, to be fair, we are under the gun here for a product, it may just mean > that the end result of that conversation is "mysql". Personally arguments in that vain are removing just about any incentive I have to work on the problem. Greetin

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 12:44 PM, Alfred Perlstein wrote: On 4/21/14 9:38 AM, Andrew Dunstan wrote: On 04/21/2014 12:25 PM, Alfred Perlstein wrote: 1. OS developers are not the target audience for GUCs. If the OS developers want to test and can't be botherrd with building with a couple of differ

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:38 AM, Andrew Dunstan wrote: On 04/21/2014 12:25 PM, Alfred Perlstein wrote: 1. OS developers are not the target audience for GUCs. If the OS developers want to test and can't be botherrd with building with a couple of different parameters then I'm not very impressed. 2. W

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:34 AM, Stephen Frost wrote: * Alfred Perlstein (alf...@freebsd.org) wrote: There is definitely hope, however changes to the FreeBSD vm are taken as seriously as changes to core changes to Postresql's store. In addition changes to vm is somewhat in the realm of complexity of Postgres

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 12:25 PM, Alfred Perlstein wrote: 1. OS developers are not the target audience for GUCs. If the OS developers want to test and can't be botherrd with building with a couple of different parameters then I'm not very impressed. 2. We should be trying to get rid of GUCs where

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

* Alfred Perlstein (alf...@freebsd.org) wrote: > There is definitely hope, however changes to the FreeBSD vm are > taken as seriously as changes to core changes to Postresql's store. > In addition changes to vm is somewhat in the realm of complexity of > Postgresql store as well so it may not be co

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:24 AM, Andrew Dunstan wrote: On 04/21/2014 11:59 AM, Alfred Perlstein wrote: On 4/21/14 8:45 AM, Andrew Dunstan wrote: On 04/21/2014 11:39 AM, Magnus Hagander wrote: On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund mailto:and...@2ndquadrant.com>> wrote: On 2014-04-21 10:45:2

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 05:43:46PM +0200, Andres Freund wrote: > > On 2014-04-21 17:39:39 +0200, Magnus Hagander wrote: > > But do we really want a *guc* for it though? Isn't it enough (and in fact > > better) with a configure switch to pick the implementation when multiple > > are available, that

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 11:59 AM, Alfred Perlstein wrote: On 4/21/14 8:45 AM, Andrew Dunstan wrote: On 04/21/2014 11:39 AM, Magnus Hagander wrote: On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund mailto:and...@2ndquadrant.com>> wrote: On 2014-04-21 10:45:24 -0400, Tom Lane wrote: > Andres Freun

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:13 AM, Stephen Frost wrote: * Alfred Perlstein (alf...@freebsd.org) wrote: Can the package builder not set the default for the runtime tunable? Yeah, I was thinking about that also, but at least in this case it seems pretty clear that the 'right' answer is known at build time. Ho

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 2014-04-21 11:58:10 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-04-21 11:45:49 -0400, Andrew Dunstan wrote: > >> That seems to make more sense. I can't imagine why this would be a runtime > >> parameter as opposed to build time. > > > Because that implies that packagers and port

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

* Alfred Perlstein (alf...@freebsd.org) wrote: > Can the package builder not set the default for the runtime tunable? Yeah, I was thinking about that also, but at least in this case it seems pretty clear that the 'right' answer is known at build time. > Honestly we're about to select a db platfor

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Andres Freund writes: > On 2014-04-21 11:45:49 -0400, Andrew Dunstan wrote: >> That seems to make more sense. I can't imagine why this would be a runtime >> parameter as opposed to build time. > Because that implies that packagers and porters need to make that > decision. If it's a GUC people can

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 8:58 AM, Tom Lane wrote: Andres Freund writes: On 2014-04-21 11:45:49 -0400, Andrew Dunstan wrote: That seems to make more sense. I can't imagine why this would be a runtime parameter as opposed to build time. Because that implies that packagers and porters need to make that decisi

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 8:45 AM, Andrew Dunstan wrote: On 04/21/2014 11:39 AM, Magnus Hagander wrote: On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund mailto:and...@2ndquadrant.com>> wrote: On 2014-04-21 10:45:24 -0400, Tom Lane wrote: > Andres Freund mailto:and...@2ndquadrant.com>> writes: > >

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, On 2014-04-21 11:45:49 -0400, Andrew Dunstan wrote: > That seems to make more sense. I can't imagine why this would be a runtime > parameter as opposed to build time. Because that implies that packagers and porters need to make that decision. If it's a GUC people can benchmark it and decide.

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 11:39 AM, Magnus Hagander wrote: On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund > wrote: On 2014-04-21 10:45:24 -0400, Tom Lane wrote: > Andres Freund mailto:and...@2ndquadrant.com>> writes: > > If there are indeed such large regressions

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, On 2014-04-21 17:39:39 +0200, Magnus Hagander wrote: > But do we really want a *guc* for it though? Isn't it enough (and in fact > better) with a configure switch to pick the implementation when multiple > are available, that could then be set by default for example by the freebsd > ports buil

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund wrote: > On 2014-04-21 10:45:24 -0400, Tom Lane wrote: > > Andres Freund writes: > > > If there are indeed such large regressions on FreeBSD we need to treat > > > them as postgres regressions. It's nicer not to add config options for > > > things th

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 2014-04-21 10:45:24 -0400, Tom Lane wrote: > Andres Freund writes: > > If there are indeed such large regressions on FreeBSD we need to treat > > them as postgres regressions. It's nicer not to add config options for > > things that don't need it, but apparently that's not the case here. > > >

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Andres Freund writes: > If there are indeed such large regressions on FreeBSD we need to treat > them as postgres regressions. It's nicer not to add config options for > things that don't need it, but apparently that's not the case here. > Imo this means we need to add GUC to control wether anon

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 4:10 AM, Andres Freund wrote: Hi, On 2014-04-20 11:24:38 +0200, Palle Girgensohn wrote: I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm wondering who to poke to mitigate the problem. In reference to this thread [1], who where the FreeBSD people that Fra

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, On 2014-04-20 11:24:38 +0200, Palle Girgensohn wrote: > I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm > wondering who to poke to mitigate the problem. In reference to this thread > [1], who where the FreeBSD people that Francois mentioned? If mmap needs to > p

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> 21 apr 2014 kl. 11:26 skrev Francois Tigeot : > >> On Sun, Apr 20, 2014 at 04:07:25PM +0200, Palle Girgensohn wrote: >> If mmap needs to perform well in the kernel, I'd like to know of someone with FreeBSD kernel knowledge who is interested in working with mmap perfocmance. I

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On Sun, Apr 20, 2014 at 04:07:25PM +0200, Palle Girgensohn wrote: > > >> If mmap needs to perform well in the kernel, I'd like to know of someone > >> with FreeBSD kernel knowledge who is interested in working with mmap > >> perfocmance. If mmap is indeed the cuplrit, I've just tested 9.2.8 vs

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> 20 apr 2014 kl. 12:19 skrev Francois Tigeot : > > Hi, > >> On Sun, Apr 20, 2014 at 11:24:38AM +0200, Palle Girgensohn wrote: >> >> I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm >> wondering who to poke to mitigate the problem. In reference to this thread >> [1

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, On Sun, Apr 20, 2014 at 11:24:38AM +0200, Palle Girgensohn wrote: > > I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm > wondering who to poke to mitigate the problem. In reference to this thread > [1], who where the FreeBSD people that Francois mentioned? At le