On Tue, Oct 11, 2016 at 8:08 PM, Torsten Zuehlsdorff
wrote:
> On 28.09.2016 23:39, Thomas Munro wrote:
>> It's difficult to draw any conclusions at this point.
>
> I'm currently setting up a new FreeBSD machine. Its a FreeBSD 11 with ZFS,
> 64 GB RAM and Quad Core. If you're interested in i can gi
On 28.09.2016 23:39, Thomas Munro wrote:
On Thu, Sep 29, 2016 at 9:09 AM, Keith Fiske wrote:
On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro
wrote:
Ok, here's a version tweaked to use EVFILT_PROC for postmaster death
detection instead of the pipe, as Tom Lane suggested in another
thread[1].
[
On Thu, Sep 29, 2016 at 9:09 AM, Keith Fiske wrote:
> On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro
> wrote:
>> Ok, here's a version tweaked to use EVFILT_PROC for postmaster death
>> detection instead of the pipe, as Tom Lane suggested in another
>> thread[1].
>>
>> [...]
>
> Ran benchmarks on
On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro <
thomas.mu...@enterprisedb.com> wrote:
> On Thu, Sep 15, 2016 at 11:04 AM, Thomas Munro
> wrote:
> > On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske wrote:
> >> Thomas Munro brought up in #postgresql on freenode needing someone to
> test a
> >> patch
Hi,
On 16/09/2016 05:11, Thomas Munro wrote:
Still no change measurable on my laptop. Keith, would you be able to
test this on your rig and see if it sucks any less than the last one?
I've tested kqueue-v6.patch on the Celeron NetBSD machine and numbers
were constantly lower by about 5-10% v
On Thu, Sep 15, 2016 at 11:04 AM, Thomas Munro
wrote:
> On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske wrote:
>> Thomas Munro brought up in #postgresql on freenode needing someone to test a
>> patch on a larger FreeBSD server. I've got a pretty decent machine (3.1Ghz
>> Quad Core Xeon E3-1220V3, 1
On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske wrote:
> Thomas Munro brought up in #postgresql on freenode needing someone to test a
> patch on a larger FreeBSD server. I've got a pretty decent machine (3.1Ghz
> Quad Core Xeon E3-1220V3, 16GB ECC RAM, ZFS mirror on WD Red HDD) so offered
> to give
On Wed, Sep 14, 2016 at 9:09 AM, Matteo Beccati wrote:
> Hi,
>
> On 14/09/2016 00:06, Tom Lane wrote:
>
>> I'm inclined to think the kqueue patch is worth applying just on the
>> grounds that it makes things better on OS X and doesn't seem to hurt
>> on FreeBSD. Whether anyone would ever get to
Hi,
On 14/09/2016 00:06, Tom Lane wrote:
I'm inclined to think the kqueue patch is worth applying just on the
grounds that it makes things better on OS X and doesn't seem to hurt
on FreeBSD. Whether anyone would ever get to the point of seeing
intra-kernel contention on these platforms is hard
On Wed, Sep 14, 2016 at 3:32 PM, Tom Lane wrote:
> Michael Paquier writes:
>> From an OSX laptop with -S, -c 1 and -M prepared (9 runs, removed the
>> three best and three worst):
>> - HEAD: 9356/9343/9369
>> - HEAD + patch: 9433/9413/9461.071168
>> This laptop has a lot of I/O overhead... Still
Michael Paquier writes:
> From an OSX laptop with -S, -c 1 and -M prepared (9 runs, removed the
> three best and three worst):
> - HEAD: 9356/9343/9369
> - HEAD + patch: 9433/9413/9461.071168
> This laptop has a lot of I/O overhead... Still there is a slight
> improvement here as well. Looking at
On Wed, Sep 14, 2016 at 7:06 AM, Tom Lane wrote:
> It would be good for someone else to reproduce my results though.
> For one thing, 5%-ish is not that far above the noise level; maybe
> what I'm measuring here is just good luck from relocation of critical
> loops into more cache-line-friendly lo
On Wed, Sep 14, 2016 at 12:06 AM, Tom Lane wrote:
> I wrote:
>> At -j 10 -c 10, all else the same, I get 84928 TPS on HEAD and 90357
>> with the patch, so about 6% better.
>
> And at -j 1 -c 1, I get 22390 and 24040 TPS, or about 7% better with
> the patch. So what I am seeing on OS X isn't conte
I wrote:
> At -j 10 -c 10, all else the same, I get 84928 TPS on HEAD and 90357
> with the patch, so about 6% better.
And at -j 1 -c 1, I get 22390 and 24040 TPS, or about 7% better with
the patch. So what I am seeing on OS X isn't contention of any sort,
but just a straight speedup that's indepe
Andres Freund writes:
> On 2016-09-13 15:37:22 -0400, Tom Lane wrote:
>> (It's a 4-core CPU so I saw little point in pressing harder than
>> that.)
> I think in reality most busy machines, were performance and scalability
> matter, are overcommitted in the number of connections vs. cores. And
>
On 2016-09-13 15:37:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-13 14:47:08 -0400, Tom Lane wrote:
> >> Also I notice that the WaitEventSet thread started with a simple
> >> pgbench test, so I don't really buy the claim that that's not a
> >> way that will reach the problem.
>
Andres Freund writes:
> On 2016-09-13 14:47:08 -0400, Tom Lane wrote:
>> Also I notice that the WaitEventSet thread started with a simple
>> pgbench test, so I don't really buy the claim that that's not a
>> way that will reach the problem.
> You can reach it, but not when using 1 core:one pgbenc
Andres Freund writes:
> On 2016-09-13 12:43:36 -0400, Tom Lane wrote:
>> Also, if it's only a win on machines with dozens of CPUs, how many
>> people are running *BSD on that kind of iron? I think Linux is by
>> far the dominant kernel for such hardware. For sure Apple isn't
>> selling any machi
On 2016-09-13 14:47:08 -0400, Tom Lane wrote:
> Also I notice that the WaitEventSet thread started with a simple
> pgbench test, so I don't really buy the claim that that's not a
> way that will reach the problem.
You can reach it, but not when using 1 core:one pgbench thread:one
client connection
On 2016-09-13 12:43:36 -0400, Tom Lane wrote:
> > I think it's not necessarily about the current system, but more about
> > future uses of the WaitEventSet stuff. Some of that is going to use a
> > lot more sockets. E.g. doing a parallel append over FDWs.
(note that I'm talking about network socke
Andres Freund writes:
> On 2016-09-13 16:08:39 +0300, Heikki Linnakangas wrote:
>> So, if I've understood correctly, the purpose of this patch is to improve
>> performance on a multi-CPU system, which has the kqueue() function. Most
>> notably, FreeBSD?
> I think it's not necessarily about the cu
On Tue, Sep 13, 2016 at 11:36 AM, Simon Riggs wrote:
> On 13 September 2016 at 08:08, Heikki Linnakangas wrote:
>> So, if I've understood correctly, the purpose of this patch is to improve
>> performance on a multi-CPU system, which has the kqueue() function. Most
>> notably, FreeBSD?
>
> I'm get
On 13 September 2016 at 08:08, Heikki Linnakangas wrote:
> So, if I've understood correctly, the purpose of this patch is to improve
> performance on a multi-CPU system, which has the kqueue() function. Most
> notably, FreeBSD?
I'm getting a little fried from "self-documenting" patches, from
mul
Hi,
On 2016-09-13 16:08:39 +0300, Heikki Linnakangas wrote:
> So, if I've understood correctly, the purpose of this patch is to improve
> performance on a multi-CPU system, which has the kqueue() function. Most
> notably, FreeBSD?
I think it's not necessarily about the current system, but more a
On 09/13/2016 04:33 PM, Tom Lane wrote:
Heikki Linnakangas writes:
So, if I've understood correctly, the purpose of this patch is to
improve performance on a multi-CPU system, which has the kqueue()
function. Most notably, FreeBSD?
OS X also has this, so it might be worth trying on a multi-CP
Heikki Linnakangas writes:
> So, if I've understood correctly, the purpose of this patch is to
> improve performance on a multi-CPU system, which has the kqueue()
> function. Most notably, FreeBSD?
OS X also has this, so it might be worth trying on a multi-CPU Mac.
> If there's no measurable d
So, if I've understood correctly, the purpose of this patch is to
improve performance on a multi-CPU system, which has the kqueue()
function. Most notably, FreeBSD?
I launched a FreeBSD 10.3 instance on Amazon EC2 (ami-e0682b80), on a
m4.10xlarge instance. That's a 40 core system, biggest avai
On Wed, Sep 7, 2016 at 12:32 AM, Marko Tiikkaja wrote:
> I've tested and reviewed this, and it looks good to me, other than this
> part:
>
> + /*
> +* kevent guarantees that the change list has been processed in the
> EINTR
> +* case. Here we are only applying a change list so EINTR cou
On 2016-06-03 01:45, Thomas Munro wrote:
On Fri, Jun 3, 2016 at 4:02 AM, Alvaro Herrera wrote:
Tom Lane wrote:
Andres Freund writes:
pg_strtoi?
I think that's what Thomas did upthread. Are you taking this one then?
I'd go with just "strtoint". We have "strtoint64" elsewhere.
For clos
On Fri, Jun 3, 2016 at 4:02 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Andres Freund writes:
>> >> pg_strtoi?
>>
>> > I think that's what Thomas did upthread. Are you taking this one then?
>>
>> I'd go with just "strtoint". We have "strtoint64" elsewhere.
>
> For closure of this subthread: t
Tom Lane wrote:
> Andres Freund writes:
> >> pg_strtoi?
>
> > I think that's what Thomas did upthread. Are you taking this one then?
>
> I'd go with just "strtoint". We have "strtoint64" elsewhere.
For closure of this subthread: this rename was committed by Tom as
0ab3595e5bb5.
--
Álvaro Her
Andres Freund writes:
>> pg_strtoi?
> I think that's what Thomas did upthread. Are you taking this one then?
I'd go with just "strtoint". We have "strtoint64" elsewhere.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Thomas Munro writes:
> On Sat, Apr 23, 2016 at 4:36 AM, Andres Freund wrote:
>> On 2016-04-22 20:39:27 +1200, Thomas Munro wrote:
>>> While doing that I discovered that unpatched master doesn't actually
>>> build on recent NetBSD systems because our static function strtoi
>>> clashes with a non-s
On 2016-04-22 19:25:06 -0300, Alvaro Herrera wrote:
> Since we haven't, maybe nobody cares, so why should we?
I guess it's to a good degree because netbsd has pg packages, and it's
fixed there?
> would rename our function nonetheless FWIW; the name seems far too
> generic to me.
Yea.
> pg_strto
On 2016-04-23 10:12:12 +1200, Thomas Munro wrote:
> What is the policy for that kind of thing -- do nothing until someone
> cares enough about the platform to supply a buildfarm animal?
I think we should fix it, I just want to make sure we understand why the
error is appearing now. Since we now do
Thomas Munro wrote:
> On Sat, Apr 23, 2016 at 4:36 AM, Andres Freund wrote:
> > On 2016-04-22 20:39:27 +1200, Thomas Munro wrote:
> >> While doing that I discovered that unpatched master doesn't actually
> >> build on recent NetBSD systems because our static function strtoi
> >> clashes with a non
On Sat, Apr 23, 2016 at 4:36 AM, Andres Freund wrote:
> On 2016-04-22 20:39:27 +1200, Thomas Munro wrote:
>> While doing that I discovered that unpatched master doesn't actually
>> build on recent NetBSD systems because our static function strtoi
>> clashes with a non-standard libc function of the
On 2016-04-22 20:39:27 +1200, Thomas Munro wrote:
> I vote to leave this patch in the next commitfest where it is, and
> reconsider if someone shows up with a relevant problem report on large
> systems.
Sounds good!
> Here's a new version of the patch that fixes some stupid bugs. I have
> run r
On Fri, Apr 22, 2016 at 12:21 PM, Andres Freund wrote:
> On 2016-04-21 14:25:06 -0400, Robert Haas wrote:
>> On Thu, Apr 21, 2016 at 2:22 PM, Andres Freund wrote:
>> > On 2016-04-21 14:15:53 -0400, Robert Haas wrote:
>> >> On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
>> >> wrote:
>> >> > On the
On 2016-04-21 14:25:06 -0400, Robert Haas wrote:
> On Thu, Apr 21, 2016 at 2:22 PM, Andres Freund wrote:
> > On 2016-04-21 14:15:53 -0400, Robert Haas wrote:
> >> On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
> >> wrote:
> >> > On the WaitEventSet thread I posted a small patch to add kqueue
> >>
On Thu, Apr 21, 2016 at 3:31 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Thu, Apr 21, 2016 at 2:22 PM, Andres Freund wrote:
>> > On 2016-04-21 14:15:53 -0400, Robert Haas wrote:
>> >> On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
>> >> wrote:
>> >> > On the WaitEventSet thread I posted
Robert Haas wrote:
> On Thu, Apr 21, 2016 at 2:22 PM, Andres Freund wrote:
> > On 2016-04-21 14:15:53 -0400, Robert Haas wrote:
> >> On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
> >> wrote:
> >> > On the WaitEventSet thread I posted a small patch to add kqueue
> >> > support[1]. Since then I pe
On Thu, Apr 21, 2016 at 2:22 PM, Andres Freund wrote:
> On 2016-04-21 14:15:53 -0400, Robert Haas wrote:
>> On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
>> wrote:
>> > On the WaitEventSet thread I posted a small patch to add kqueue
>> > support[1]. Since then I peeked at how some other software
On 2016-04-21 14:15:53 -0400, Robert Haas wrote:
> On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
> wrote:
> > On the WaitEventSet thread I posted a small patch to add kqueue
> > support[1]. Since then I peeked at how some other software[2]
> > interacts with kqueue and discovered that there are p
On Tue, Mar 29, 2016 at 7:53 PM, Thomas Munro
wrote:
> On the WaitEventSet thread I posted a small patch to add kqueue
> support[1]. Since then I peeked at how some other software[2]
> interacts with kqueue and discovered that there are platforms
> including NetBSD where kevent.udata is an intptr
Hi,
On the WaitEventSet thread I posted a small patch to add kqueue
support[1]. Since then I peeked at how some other software[2]
interacts with kqueue and discovered that there are platforms
including NetBSD where kevent.udata is an intptr_t instead of a void
*. Here's a version which should co
46 matches
Mail list logo
