>
> Can we make this the last post on this topic please?
>
+1 :)
Thanks,
Pavan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 9, 2011 at 2:13 PM, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs wrote:
>> I have asked that we maintain the Reasonableness we have always had
>> about how the feature freeze date was applied. An example of such
>> reasonableness is that if a feature is a few days
On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs wrote:
> I have asked that we maintain the Reasonableness we have always had
> about how the feature freeze date was applied. An example of such
> reasonableness is that if a feature is a few days late and it is
> important, then it would still go into t
On Wed, Jun 8, 2011 at 6:43 PM, Joshua Berkus wrote:
> Simon,
>
>> The point I have made is that I disagree with a feature freeze date
>> fixed ahead of time without regard to the content of the forthcoming
>> release. I've not said I disagree with feature freezes altogether,
>> which would be utt
Joshua Berkus writes:
> Simon,
>> The point I have made is that I disagree with a feature freeze date
>> fixed ahead of time without regard to the content of the forthcoming
>> release. I've not said I disagree with feature freezes altogether,
>> which would be utterly ridiculous. Fixed dates are
Simon Riggs writes:
> On Wed, Jun 8, 2011 at 6:02 AM, Tom Lane wrote:
>> Just to set the record straight on this ... the vxid patch went in on
>> 2007-09-05:
>> http://archives.postgresql.org/pgsql-committers/2007-09/msg00026.php
>> which was a day shy of a month before we wrapped 8.3beta1:
>> ht
On Wed, Jun 8, 2011 at 1:10 PM, Simon Riggs wrote:
> Why do you address this to me? Many others have been committing
> patches against raised issues well after feature freeze.
No one other than you has proposed committing anything nearly as
invasive as this, and the great majority of what we've c
On 06/07/2011 11:55 AM, Tom Lane wrote:
Simon Riggs writes:
Before you arrived, it was quite normal to suggest tuning patches
after feature freeze.
*Low risk* tuning patches make sense at this stage, yes. Fooling with
the lock mechanisms doesn't qualify as low risk in my book. The
probabili
Simon,
> The point I have made is that I disagree with a feature freeze date
> fixed ahead of time without regard to the content of the forthcoming
> release. I've not said I disagree with feature freezes altogether,
> which would be utterly ridiculous. Fixed dates are IMHO much less
> important t
On Wed, Jun 8, 2011 at 5:44 PM, Robert Haas wrote:
> On Wed, Jun 8, 2011 at 12:25 PM, Simon Riggs wrote:
>> As a result of this, I've been insulted, told I have no respect for
>> process and even suggested there was a threat of patch war.
>
> Well, you've pretty much said flat out you don't like
On Wed, Jun 8, 2011 at 5:32 PM, Robert Haas wrote:
> It took me
> about 3 days to write the patch. I've now spent the better part of a
> day on this scheduling discussion. I would rather have spent that
> time improving the patch. Or working on some other patch. Or getting
> 9.1 out the door.
On Wed, Jun 8, 2011 at 12:25 PM, Simon Riggs wrote:
> As a result of this, I've been insulted, told I have no respect for
> process and even suggested there was a threat of patch war.
Well, you've pretty much said flat out you don't like the process, and
you don't agree with having a firm feature
On Wed, Jun 8, 2011 at 5:33 AM, Bruce Momjian wrote:
> One more thing --- when Tom applied that patch during 8.3 beta it was
> with everyone's agreement, so the policy should be that if we are going
> to break the rules, everyone has to agree --- if anyone disagrees, the
> rules stand.
I spoke a
On Wed, Jun 8, 2011 at 6:02 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Simon is right that we slipped the vxid patch into 8.3 when a Postgres
>> user I talked to at Linuxworld mentioned high vacuum freeze activity and
>> simple calculations showed the many read-only queries could cause high
>
On Wed, Jun 8, 2011 at 11:39 AM, Jim Nasby wrote:
> On Jun 7, 2011, at 8:24 AM, Stephen Frost wrote:
>> * Alvaro Herrera (alvhe...@commandprompt.com) wrote:
>>> I note that if 2nd Quadrant is interested in having a game-changing
>>> platform without having to wait a full year for 9.2, they can obv
On Wed, Jun 8, 2011 at 5:19 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs wrote:
>> > My point was that we have in the past implemented performance changes
>> > to increase scalability at the last minute, and also that our personal
>> > risk perspec
On Jun 7, 2011, at 8:24 AM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@commandprompt.com) wrote:
>> I note that if 2nd Quadrant is interested in having a game-changing
>> platform without having to wait a full year for 9.2, they can obviously
>> distribute a modified version of Postgres that
Bruce Momjian writes:
> Simon is right that we slipped the vxid patch into 8.3 when a Postgres
> user I talked to at Linuxworld mentioned high vacuum freeze activity and
> simple calculations showed the many read-only queries could cause high
> xid usage. Fortunately we already had a patch availa
Bruce Momjian wrote:
> Simon is right that we slipped the vxid patch into 8.3 when a Postgres
> user I talked to at Linuxworld mentioned high vacuum freeze activity and
> simple calculations showed the many read-only queries could cause high
> xid usage. Fortunately we already had a patch availabl
Robert Haas wrote:
> On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs wrote:
> > My point was that we have in the past implemented performance changes
> > to increase scalability at the last minute, and also that our personal
> > risk perspectives are not always set in stone.
> >
> > Robert has highli
Excerpts from Robert Haas's message of mar jun 07 13:53:23 -0400 2011:
> On Tue, Jun 7, 2011 at 1:45 PM, Thom Brown wrote:
> > Speaking of which, is it now safe to remove the "NOT VALID constraints
> > don't dump properly" issue from the blocker list since the fix has
> > been committed?
>
> I ho
On 6/7/11 1:11 PM, Simon Riggs wrote:
>> that appear low risk. I seriously doubt that I would consider *any*
>> > meaningful change in the locking area to be low risk.
> That's a shame. We'll fix it in 9.2 then.
I will point out that we bounced Alvaro's FK patch, which *was*
submitted in time for
On Tue, Jun 7, 2011 at 5:43 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 9:52 PM, Robert Haas wrote:
>> If we were to fix ONLY the vxid issue in 9.1 as you were advocating
>
> Sensible debate is impossible when you don't read what I've written.
I've read every word you've written on this thre
On Tue, Jun 7, 2011 at 9:52 PM, Robert Haas wrote:
> If we were to fix ONLY the vxid issue in 9.1 as you were advocating
Sensible debate is impossible when you don't read what I've written.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Tra
On Tue, Jun 7, 2011 at 12:51 PM, Simon Riggs wrote:
> Stefan/Robert's observation that we perform a
> VirtualXactLockTableInsert() to no real benefit is a good one.
>
> It leads to the following simple patch to remove one lock table hit
> per transaction. It's a lot smaller impact on the LockMgr l
On Tue, Jun 7, 2011 at 9:00 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Moving on from that, I have proposed other solutions. Koichi, Jignesh
>> and and then Robert have shown measurements of the huge contention in
>> this area of our software. Robert's patch addresses the problems, as
>> do Koi
On Tue, Jun 7, 2011 at 3:44 PM, Jignesh Shah wrote:
> On Mon, Jun 6, 2011 at 11:20 PM, Jignesh Shah wrote:
>> Okay I tried it out with sysbench read scaling test..
>> Note I had tried that earlier on 9.0
>> http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html
>>
>> And on t
Simon Riggs writes:
> Moving on from that, I have proposed other solutions. Koichi, Jignesh
> and and then Robert have shown measurements of the huge contention in
> this area of our software. Robert's patch addresses the problems, as
> do Koichi's and my latest patch. I would like to see us do
>
On Tue, Jun 7, 2011 at 7:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Before you arrived, it was quite normal to suggest tuning patches
>> after feature freeze.
>
> *Low risk* tuning patches make sense at this stage, yes. Fooling with
> the lock mechanisms doesn't qualify as low risk in my bo
Robert Haas writes:
> I plead guilty to taking my eye off the ball post-beta1. I busted my
> ass for two months stabilizing other people's code after CF4 was over,
> and then I moved on to other things. I will try to get my eye back on
> the ball - but actually I'm not sure there's all that much
On Mon, Jun 6, 2011 at 11:20 PM, Jignesh Shah wrote:
>
> Okay I tried it out with sysbench read scaling test..
> Note I had tried that earlier on 9.0
> http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html
>
> And on that test I found that doing that test on anything bigger
Simon Riggs writes:
> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.
*Low risk* tuning patches make sense at this stage, yes. Fooling with
the lock mechanisms doesn't qualify as low risk in my book. The
probability of undetected subtle problems is just
On Tue, Jun 7, 2011 at 2:06 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 6:33 PM, Robert Haas wrote:
>> On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
>>> As long as we have solidarity of the committers that this is not allowed,
>>> however, this is not a real problem. And it appears
Simon Riggs wrote:
> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.
I've worn a lot of hats in the practical end of this industry, and
regardless of which perspective I look at this from, I can't think
of anything so destructive to productivity, devel
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.
I haven't been around as long as some, but I think I've been around
longer than Robert, and I can say that I don't recall serious
performance patches, particular
On Tue, Jun 7, 2011 at 6:33 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
>> As long as we have solidarity of the committers that this is not allowed,
>> however, this is not a real problem. And it appears that we do. In the
>> future, it shouldn't even be nece
Robert Haas writes:
> On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
>> As long as we have solidarity of the committers that this is not allowed,
>> however, this is not a real problem. And it appears that we do. In the
>> future, it shouldn't even be necessary to discuss it.
> Solidar
On Tue, Jun 7, 2011 at 1:45 PM, Thom Brown wrote:
> Speaking of which, is it now safe to remove the "NOT VALID constraints
> don't dump properly" issue from the blocker list since the fix has
> been committed?
I hope so, because I just did that (before noticing this email from you).
--
Robert H
On Tue, Jun 7, 2011 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I think at the next developer meeting we're going to
>> get to hear Tom argue that overlapping the end of beta with the
>> beginning of the next release cycle is a mistake and we should go back
>> to the old system where
On 7 June 2011 19:32, Tom Lane wrote:
> Joshua Berkus writes:
>> Actually, the summer is *excellent* from a publicity perspective ... at
>> least, June and July are. Both of those months are full of US conferences
>> whose PR we can piggyback on to make a splash.
>
>> August is really the only
On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
> As long as we have solidarity of the committers that this is not allowed,
> however, this is not a real problem. And it appears that we do. In the
> future, it shouldn't even be necessary to discuss it.
Solidarity?
Simon - who was a comm
Joshua Berkus writes:
> Actually, the summer is *excellent* from a publicity perspective ... at
> least, June and July are. Both of those months are full of US conferences
> whose PR we can piggyback on to make a splash.
> August is really the only "bad" month from a PR perspective, because we
Robert,
> Oh, I get that. I'm just dismayed that we can't have a discussion
> about the patch without getting sidetracked into a conversation about
> whether we should throw feature freeze out the window.
That's not something you can change. Whatever the patch is, even if it's a
psql improveme
Robert Haas writes:
> ... I think at the next developer meeting we're going to
> get to hear Tom argue that overlapping the end of beta with the
> beginning of the next release cycle is a mistake and we should go back
> to the old system where we yell at everyone to shut up unless they're
> helpin
> iew. The
> reason we usually skip the summer isn't actually a wholesale lack of
> people - it's because it's not so good from a publicity perspective,
> and it's hard to get all the packagers around at the same time.
Actually, the summer is *excellent* from a publicity perspective ... at least,
Simon Riggs writes:
> Please consider this as a serious proposal for tuning in 9.1.
Look: it is at least four months too late for anything of the sort in 9.1.
We should be fixing bugs, and nothing else, if we ever want to get 9.1
out the door. Performance improvements don't qualify, especially n
On Tue, Jun 7, 2011 at 11:56 AM, Joshua D. Drake wrote:
> On 06/06/2011 04:43 PM, Robert Haas wrote:
>>
>> On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
>> wrote:
>>>
>>> Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
I've now spent enough time working on this
On Tue, Jun 7, 2011 at 12:51 PM, Simon Riggs wrote:
> On Mon, Jun 6, 2011 at 8:50 PM, Dave Page wrote:
>> On Mon, Jun 6, 2011 at 8:40 PM, Stefan Kaltenbrunner
>> wrote:
>>> On 06/06/2011 09:24 PM, Dave Page wrote:
On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
wrote:
> So, to t
On Mon, Jun 6, 2011 at 8:50 PM, Dave Page wrote:
> On Mon, Jun 6, 2011 at 8:40 PM, Stefan Kaltenbrunner
> wrote:
>> On 06/06/2011 09:24 PM, Dave Page wrote:
>>> On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
>>> wrote:
So, to the question “do we want hard deadlines?” I think the answer i
On 06/06/2011 04:43 PM, Robert Haas wrote:
On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
I've now spent enough time working on this issue now to be convinced
that the approach has merit, if we can work out the kink
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> I note that if 2nd Quadrant is interested in having a game-changing
> platform without having to wait a full year for 9.2, they can obviously
> distribute a modified version of Postgres that integrates Robert's
> patch.
Having thought about th
On Tue, Jun 7, 2011 at 12:29 AM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
>>> If we're going to start putting in changes like this, I'd suggest that
>>> we try and target something like September for 9.1 to actually be
>>> released. Playing wit
On Mon, Jun 6, 2011 at 2:49 PM, Josh Berkus wrote:
>
>> That's an improvement of about ~3.5x. According to the vmstat output,
>> when running without the patch, the CPU state was about 40% idle.
>> With the patch, it dropped down to around 6%.
>
> Wow! That's fantastic.
>
> Jignesh, are you in a
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I see no reason to delay from a July release as has long been planned.
>
> What open items are genuine blockers?
>
> If we need deadlines anywhere its in beta and final release, otherwise
> we all just sit around shrugging and saying "another week I
On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
>> I've now spent enough time working on this issue now to be convinced
>> that the approach has merit, if we can work out the kinks. I'll start
>> with some performance
Dave Page writes:
> On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
>> If we're going to start putting in changes like this, I'd suggest that
>> we try and target something like September for 9.1 to actually be
>> released. Playing with the lock management isn't something we want to
>> be d
Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
> I've now spent enough time working on this issue now to be convinced
> that the approach has merit, if we can work out the kinks. I'll start
> with some performance numbers.
I hereby recommend that people with patches such a
Excerpts from Dimitri Fontaine's message of lun jun 06 15:12:54 -0400 2011:
> So, to the question “do we want hard deadlines?” I think the answer is
> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
> the question “does this very change should be considered this late?” my
>
On Mon, Jun 6, 2011 at 8:52 PM, Dave Page wrote:
> On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
>> * Dave Page (dp...@pgadmin.org) wrote:
>>> Much as I hate to say it (I too want to keep our schedule as
>>> predictable and organised as possible), I have to agree. Assuming the
>>> patch is
Stephen Frost wrote:
> if people really want this in, then we need to figure out what the
> new schedule is going to be.
I suggest June, 2012. That way we can get a whole bunch more really
cool patches in, and the users won't have to wait for 9.2 to get
them.
-Kevin
--
Sent via pgsql-hack
On Mon, Jun 6, 2011 at 3:59 PM, Christopher Browne wrote:
> On Mon, Jun 6, 2011 at 5:13 PM, Simon Riggs wrote:
>> The cost to us is a few days work and the benefit is a whole year's
>> worth of increased performance for our user base, which has a hardware
>> equivalent well into the millions of d
On Mon, Jun 6, 2011 at 5:13 PM, Simon Riggs wrote:
> The cost to us is a few days work and the benefit is a whole year's
> worth of increased performance for our user base, which has a hardware
> equivalent well into the millions of dollars.
I doubt that this is an accurate reflection of the cost
On Mon, Jun 6, 2011 at 2:49 PM, Josh Berkus wrote:
>
>> That's an improvement of about ~3.5x. According to the vmstat output,
>> when running without the patch, the CPU state was about 40% idle.
>> With the patch, it dropped down to around 6%.
>
> Wow! That's fantastic.
>
> Jignesh, are you in a
On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
> * Dave Page (dp...@pgadmin.org) wrote:
>> Much as I hate to say it (I too want to keep our schedule as
>> predictable and organised as possible), I have to agree. Assuming the
>> patch is good, I think this is something we should push into 9.1
On 06/06/2011 03:24 PM, Dave Page wrote:
On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine wrote:
So, to the question “do we want hard deadlines?” I think the answer is
“no”, to “do we need hard deadlines?”, my answer is still “no”, and to
the question “does this very change should be consider
On 6/6/11 12:12 PM, Dimitri Fontaine wrote:
> So, to the question “do we want hard deadlines?” I think the answer is
> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
> the question “does this very change should be considered this late?” my
> answer is yes.
I could not disag
On Mon, Jun 6, 2011 at 8:40 PM, Stefan Kaltenbrunner
wrote:
> On 06/06/2011 09:24 PM, Dave Page wrote:
>> On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
>> wrote:
>>> So, to the question “do we want hard deadlines?” I think the answer is
>>> “no”, to “do we need hard deadlines?”, my answer is
* Dave Page (dp...@pgadmin.org) wrote:
> Much as I hate to say it (I too want to keep our schedule as
> predictable and organised as possible), I have to agree. Assuming the
> patch is good, I think this is something we should push into 9.1. It
> really could be a game changer.
So, with folks putt
On 06/06/2011 09:24 PM, Dave Page wrote:
> On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
> wrote:
>> So, to the question “do we want hard deadlines?” I think the answer is
>> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
>> the question “does this very change should be
On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine wrote:
> So, to the question “do we want hard deadlines?” I think the answer is
> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
> the question “does this very change should be considered this late?” my
> answer is yes.
>
> B
Robert Haas writes:
> IMHO, it's better to just have a deadline,
Well, that's the fine point we're now talking about.
I still think that we should try at making the best release possible.
And if that means including changes at beta time because that's when
someone got around to doing them, so
> That's an improvement of about ~3.5x. According to the vmstat output,
> when running without the patch, the CPU state was about 40% idle.
> With the patch, it dropped down to around 6%.
Wow! That's fantastic.
Jignesh, are you in a position to test any of Robert's work using DBT or
other benc
On Mon, Jun 6, 2011 at 5:14 PM, Kevin Grittner
wrote:
> Perhaps the best way to describe the suggestion that this be
> included in 9.1 isn't that it's an insane suggestion; but that it's
> a suggestion which, if adopted, would be likely to drive those who
> are striving for a more organized devel
Robert Haas wrote:
> IMHO, it's better to just have a deadline, and stuff either makes
> it or it doesn't. I realize we haven't always adhered to the
> principle in the past, but at least IMV that's not a mistake we
> want to continue repeating.
+1
I've said it before, but I think it bears
On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs wrote:
> My point was that we have in the past implemented performance changes
> to increase scalability at the last minute, and also that our personal
> risk perspectives are not always set in stone.
>
> Robert has highlighted the value of this change
On Mon, Jun 6, 2011 at 11:19 AM, Heikki Linnakangas
wrote:
> On 06.06.2011 12:40, Simon Riggs wrote:
>>
>> On Sat, Jun 4, 2011 at 5:55 PM, Tom Lane wrote:
>>>
>>> Simon Riggs writes:
The approach looks sound to me. It's a fairly isolated patch and we
should be considering this for
On 06.06.2011 14:59, Robert Haas wrote:
BTW, how do you identify from oprofile that *vxid* locks were the
problem? I didn't think it could produce that level of detail.
It can show the call stack of each call, with --callgraph=n option,
where you can see what percentage of the calls to LockAc
On Mon, Jun 6, 2011 at 8:02 AM, Heikki Linnakangas
wrote:
> On 06.06.2011 07:12, Robert Haas wrote:
>>
>> I did some further investigation of this. It appears that more than
>> 99% of the lock manager lwlock traffic that remains with this patch
>> applied has locktag_type == LOCKTAG_VIRTUALTRANSA
On 06.06.2011 07:12, Robert Haas wrote:
I did some further investigation of this. It appears that more than
99% of the lock manager lwlock traffic that remains with this patch
applied has locktag_type == LOCKTAG_VIRTUALTRANSACTION. Every SELECT
statement runs in a separate transaction, and for
On Mon, Jun 6, 2011 at 2:54 AM, Heikki Linnakangas
wrote:
> Ah, I remember I saw that vxid lock pop up quite high in an oprofile profile
> recently. I think it was the case of executing a lot of very simple prepared
> queries. So it would be nice to address that, even from a single CPU point
> of
On 06.06.2011 12:40, Simon Riggs wrote:
On Sat, Jun 4, 2011 at 5:55 PM, Tom Lane wrote:
Simon Riggs writes:
The approach looks sound to me. It's a fairly isolated patch and we
should be considering this for inclusion in 9.1, not wait another
year.
That suggestion is completely insane. The
On Sat, Jun 4, 2011 at 5:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> The approach looks sound to me. It's a fairly isolated patch and we
>> should be considering this for inclusion in 9.1, not wait another
>> year.
>
> That suggestion is completely insane. The patch is only WIP and full of
>
On 06.06.2011 07:12, Robert Haas wrote:
I did some further investigation of this. It appears that more than
99% of the lock manager lwlock traffic that remains with this patch
applied has locktag_type == LOCKTAG_VIRTUALTRANSACTION. Every SELECT
statement runs in a separate transaction, and for
On Sun, Jun 5, 2011 at 10:16 PM, Robert Haas wrote:
> I'm definitely interested in investigating what to do
> about that, but I don't think it's this patch's problem to fix all of
> our lock manager bottlenecks.
I did some further investigation of this. It appears that more than
99% of the lock
On Sun, Jun 5, 2011 at 5:46 PM, Robert Haas wrote:
> Could you compile with LWLOCK_STATS, rerun these tests, total up the
> "blk" numbers by LWLockId, and post the results? (Actually, totalling
> up the shacq and exacq numbers would be useful as well, if you
> wouldn't mind.)
I did this on the l
On Sun, Jun 5, 2011 at 4:01 PM, Stefan Kaltenbrunner
wrote:
> On 06/05/2011 09:12 PM, Heikki Linnakangas wrote:
>> On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
>>> and one for the -j80 case(also patched).
>>>
>>>
>>> 485798 48.9667 postgres s_lock
>>> 60327 6.0808 postg
On 06/05/2011 09:12 PM, Heikki Linnakangas wrote:
> On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
>> and one for the -j80 case(also patched).
>>
>>
>> 485798 48.9667 postgres s_lock
>> 60327 6.0808 postgres LWLockAcquire
>> 57049 5.7503 postgres
On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
and one for the -j80 case(also patched).
485798 48.9667 postgres s_lock
60327 6.0808 postgres LWLockAcquire
57049 5.7503 postgres LWLockRelease
18357 1.8503 postgres
On 06/03/2011 03:17 PM, Robert Haas wrote:
[...]
>
> As you can see, this works out to a bit more than a 4% improvement on
> this two-core box. I also got access (thanks to Nate Boley) to a
> 24-core box and ran the same test with scale factor 100 and
> shared_buffers=8GB. Here are the results o
Simon Riggs writes:
> The approach looks sound to me. It's a fairly isolated patch and we
> should be considering this for inclusion in 9.1, not wait another
> year.
That suggestion is completely insane. The patch is only WIP and full of
bugs, even according to its author. Even if it were solid
Simon Riggs wrote:
> we should be considering this for inclusion in 9.1, not wait
> another year.
-1
I'm really happy that we're addressing the problems with scaling to
a large number of cores, and this patch sounds great. Adding a new
feature at this point in the release cycle would be hor
On 04.06.2011 18:01, Simon Riggs wrote:
It's a fairly isolated patch and we
should be considering this for inclusion in 9.1, not wait another
year.
-1
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, Jun 4, 2011 at 2:59 PM, Simon Riggs wrote:
>> As you can see, this works out to a bit more than a 4% improvement on
>> this two-core box. I also got access (thanks to Nate Boley) to a
>> 24-core box and ran the same test with scale factor 100 and
>> shared_buffers=8GB. Here are the resu
On Fri, Jun 3, 2011 at 2:17 PM, Robert Haas wrote:
> I've now spent enough time working on this issue now to be convinced
> that the approach has merit, if we can work out the kinks.
Yes, the approach has merits and I'm sure we can work out the kinks.
> As you can see, this works out to a bit m
On Fri, Jun 3, 2011 at 10:13 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> That's an improvement of about ~3.5x.
>
> Outstanding!
>
> I don't want to even peek at this until I've posted the two WIP SSI
> patches (now both listed on the "Open Items" page), but will
> definitely take a look a
Robert Haas wrote:
> That's an improvement of about ~3.5x.
Outstanding!
I don't want to even peek at this until I've posted the two WIP SSI
patches (now both listed on the "Open Items" page), but will
definitely take a look after that.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql
96 matches
Mail list logo
