Hello,
How did this testing turn out?
Palle
3 jul 2014 kl. 12:15 skrev Tatsuo Ishii is...@postgresql.org:
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,
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 against
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
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?
CC'd
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 sfr...@snowman.net wrote:
Jim,
* Jim Nasby (j...@nasby.net) wrote:
On 4/22/14,
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
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'...
Sorry for this. I sent a
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 report to the person in
On Apr 22, 2014, at 5:07 PM, Andrew Dunstan and...@dunslane.net wrote:
On 04/22/2014 06:43 PM, Mark Wong wrote:
On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.com wrote:
On 04/22/2014 08:26 AM, Andrew Dunstan wrote:
I'm
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 point. I
On Tue, Apr 22, 2014 at 9:58 AM, Tatsuo Ishii is...@postgresql.org 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),
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
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
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 presence I think it
* 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
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
22 apr 2014 kl. 17:26 skrev Andrew Dunstan and...@dunslane.net:
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.
On 04/22/2014 08:26 AM, Andrew Dunstan wrote:
I'm going away tomorrow for a few days RR. 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
On Mon, Apr 21, 2014 at 8:06 PM, Andrew Dunstan and...@dunslane.net 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,
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
On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake j...@commandprompt.comwrote:
On 04/22/2014 08:26 AM, Andrew Dunstan wrote:
I'm going away tomorrow for a few days RR. 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
On 04/22/2014 06:43 PM, Mark Wong wrote:
On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake
j...@commandprompt.com mailto:j...@commandprompt.com wrote:
On 04/22/2014 08:26 AM, Andrew Dunstan wrote:
I'm going away tomorrow for a few days RR. when I'm back next
week I
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
- 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
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
9.3.4,
21 apr 2014 kl. 11:26 skrev Francois Tigeot ftig...@wolfpond.org:
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
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
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
Andres Freund and...@2ndquadrant.com 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
On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
If there are indeed such large regressions on FreeBSD we need to treat
them as postgres regressions. It's nicer not to
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 build?
On 04/21/2014 11:39 AM, Magnus Hagander wrote:
On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com wrote:
On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com writes:
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.
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
and...@2ndquadrant.com mailto:and...@2ndquadrant.com wrote:
On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com
On 4/21/14 8:58 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
* 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 platform
On 2014-04-21 11:58:10 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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.
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
and...@2ndquadrant.com mailto:and...@2ndquadrant.com wrote:
On 2014-04-21 10:45:24 -0400, Tom Lane
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 could
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
and...@2ndquadrant.com mailto:and...@2ndquadrant.com 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
Postgresql store as well so it may not be
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
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
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.
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
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.
Greetings,
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:
From
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
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
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
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
* 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 to
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 runtime
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.
Personally
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
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 PG.
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 ask
* 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, to
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
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 that
was
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
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 to
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
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
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 down a
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
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 that
was easy
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
On Mon, Apr 21, 2014 at 4:10 AM, Andres Freund and...@2ndquadrant.com 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
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
* 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 patch
* 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
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
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 to
On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii is...@postgresql.org 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
On 04/21/2014 09:16 PM, Peter Geoghegan wrote:
On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii is...@postgresql.org 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
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.
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:
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 least
20 apr 2014 kl. 12:19 skrev Francois Tigeot ftig...@wolfpond.org:
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
83 matches
Mail list logo
