On Wed, 18 Nov 2009, Greg Smith wrote:
Merlin Moncure wrote:
But what's up with the 400 iops measured from bonnie++?
I don't know really. SSD writes are really sensitive to block size and the
ability to chunk writes into larger chunks, so it may be that Peter has just
found the worst-case be
Merlin Moncure wrote:
But what's up with the 400 iops measured from bonnie++?
I don't know really. SSD writes are really sensitive to block size and
the ability to chunk writes into larger chunks, so it may be that Peter
has just found the worst-case behavior and everybody else is seeing
som
On 11/17/2009 01:51 PM, Greg Smith wrote:
Merlin Moncure wrote:
I am right now talking to someone on postgresql irc who is measuring
15k iops from x25-e and no data loss following power plug test.
The funny thing about Murphy is that he doesn't visit when things are
quiet. It's quite possible
On Tue, Nov 17, 2009 at 1:51 PM, Greg Smith wrote:
> Merlin Moncure wrote:
>>
>> I am right now talking to someone on postgresql irc who is measuring
>> 15k iops from x25-e and no data loss following power plug test.
>
> The funny thing about Murphy is that he doesn't visit when things are quiet.
Merlin Moncure wrote:
I am right now talking to someone on postgresql irc who is measuring
15k iops from x25-e and no data loss following power plug test.
The funny thing about Murphy is that he doesn't visit when things are
quiet. It's quite possible the window for data loss on the drive is
v
On tis, 2009-11-17 at 11:36 -0500, Merlin Moncure wrote:
> I am right now talking to someone on postgresql irc who is measuring
> 15k iops from x25-e and no data loss following power plug test. I am
> becoming increasingly suspicious that peter's results are not
> representative: given that 90% of
On Mon, 2009-11-16 at 23:57 -0500, cb wrote:
> On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
> Myself and the other guy responsible for the underlying hardware have
> already gone down this route. The big bosses know our stance and know
> it isn't us preventing the upgrade. After that, there isn
On Tue, Nov 17, 2009 at 9:54 AM, Brad Nicholson
wrote:
> On Tue, 2009-11-17 at 11:36 -0500, Merlin Moncure wrote:
>> 2009/11/13 Greg Smith :
>> > As far as what real-world apps have that profile, I like SSDs for small to
>> > medium web applications that have to be responsive, where the user shows
On Tue, 2009-11-17 at 11:36 -0500, Merlin Moncure wrote:
> 2009/11/13 Greg Smith :
> > As far as what real-world apps have that profile, I like SSDs for small to
> > medium web applications that have to be responsive, where the user shows up
> > and wants their randomly distributed and uncached dat
2009/11/13 Greg Smith :
> As far as what real-world apps have that profile, I like SSDs for small to
> medium web applications that have to be responsive, where the user shows up
> and wants their randomly distributed and uncached data with minimal latency.
> SSDs can also be used effectively as se
Wiktor Wodecki writes:
> As you can see the 8.4 run is 16 times slower. It was even worse before
> we added the index idx_b_b_date which we didn't have initially.
> Is there anything we can do about this issue? Do you need more information?
You could prevent flattening of the EXISTS subquery by a
Greg Smith wrote:
cb wrote:
My understanding is, before I joined the company, they did an upgrade
from 7 on Linux to 8 on Windows and got bit by some change in PG that
broke a bunch of code. After that, they have just refused to budge
from the 8.0.4 version we are on and know the code works ag
On Tue, Nov 17, 2009 at 7:59 AM, Kevin Grittner
wrote:
> cb wrote:
>> On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
>>
>>> Make sure you're not in the line of fire when (not if) that version
>>> eats your data. Particularly on Windows, insisting on not
>>> upgrading that version is unbelievably,
cb wrote:
> On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
>
>> Make sure you're not in the line of fire when (not if) that version
>> eats your data. Particularly on Windows, insisting on not
>> upgrading that version is unbelievably, irresponsibly stupid.
>> There are a *large* number of known b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
we are facing a performance regression regarding certain NOT EXISTS
clauses when moving from 8.3.8 to 8.4.1. It is my understanding that the
planer treats LEFT JOINs and NOT EXISTS equally with antijoin in 8.4,
but this is causing an issue for
cb wrote:
My understanding is, before I joined the company, they did an upgrade
from 7 on Linux to 8 on Windows and got bit by some change in PG that
broke a bunch of code. After that, they have just refused to budge
from the 8.0.4 version we are on and know the code works against.
Yes; that's
16 matches
Mail list logo