Tom Lane wrote:
> Dave Page writes:
> > On Wed, Jun 23, 2010 at 9:25 PM, Robert Haas wrote:
> >> I don't think we need a system-wide setting for that. ?I believe that
> >> the unlogged tables I'm working on will handle that case.
>
> > Aren't they going to be truncated at startup? If the entire
Dave Page writes:
> On Wed, Jun 23, 2010 at 9:25 PM, Robert Haas wrote:
>> I don't think we need a system-wide setting for that. I believe that
>> the unlogged tables I'm working on will handle that case.
> Aren't they going to be truncated at startup? If the entire system is
> running without
Robert Haas wrote:
> On Wed, Jun 23, 2010 at 3:37 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Dimitri Fontaine writes:
> >> > Josh Berkus writes:
> >> >> a) Eliminate WAL logging entirely
> >
> > If we elimiate WAL logging, that means a reinstall is required for even
> > a postmaster crash
On Wed, Jun 23, 2010 at 9:25 PM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 3:37 PM, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> Dimitri Fontaine writes:
>>> > Josh Berkus writes:
>>> >> a) Eliminate WAL logging entirely
>>
>> If we elimiate WAL logging, that means a reinstall is required for
On Wed, Jun 23, 2010 at 3:37 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Josh Berkus writes:
>> >> a) Eliminate WAL logging entirely
>
> If we elimiate WAL logging, that means a reinstall is required for even
> a postmaster crash, which is a new non-durable behavi
Pavel Stehule wrote:
> 2010/6/23 Bruce Momjian :
> > Tom Lane wrote:
> >> Dimitri Fontaine writes:
> >> > Josh Berkus writes:
> >> >> a) Eliminate WAL logging entirely
> >
> > If we elimiate WAL logging, that means a reinstall is required for even
> > a postmaster crash, which is a new non-durabl
2010/6/23 Bruce Momjian :
> Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Josh Berkus writes:
>> >> a) Eliminate WAL logging entirely
>
> If we elimiate WAL logging, that means a reinstall is required for even
> a postmaster crash, which is a new non-durable behavior.
>
> Also, we just added w
Tom Lane wrote:
> Dimitri Fontaine writes:
> > Josh Berkus writes:
> >> a) Eliminate WAL logging entirely
> >> b) Eliminate checkpointing
> >> c) Turn off the background writer
> >> d) Have PostgreSQL refuse to restart after a crash and instead call an
> >> exteral script (for reprovisioning)
>
Tom Lane wrote:
> Dimitri Fontaine writes:
> > Josh Berkus writes:
> >> a) Eliminate WAL logging entirely
If we elimiate WAL logging, that means a reinstall is required for even
a postmaster crash, which is a new non-durable behavior.
Also, we just added wal_level = minimal, which might end up
On Wed, Jun 23, 2010 at 3:01 PM, Anj Adu wrote:
> I have a situation where we are limited by the chassis on the box (and cost).
>
> We have a 12 x 600G hot swappable disk system (raid 10)
> and 2 internal disk ( 2x 146G)
>
> We would like to maximize storage on the large disks .
>
> Does it make
I have a situation where we are limited by the chassis on the box (and cost).
We have a 12 x 600G hot swappable disk system (raid 10)
and 2 internal disk ( 2x 146G)
We would like to maximize storage on the large disks .
Does it make sense to put the WAL and OS on the internal disks and use
the
On Wed, Jun 23, 2010 at 2:20 PM, Scott Marlowe wrote:
> On Wed, Jun 23, 2010 at 1:58 PM, Robert Haas wrote:
>> On Sun, Jun 20, 2010 at 4:13 PM, Scott Marlowe
>> wrote:
The largest consequence I can see at the moment is that when I get a
full vacuum (for preventing transaction-id wrapa
On Wed, Jun 23, 2010 at 1:58 PM, Robert Haas wrote:
> On Sun, Jun 20, 2010 at 4:13 PM, Scott Marlowe
> wrote:
>>> The largest consequence I can see at the moment is that when I get a
>>> full vacuum (for preventing transaction-id wraparound) it would be
>>
>> I assume you mean the automatic data
On Sun, Jun 20, 2010 at 4:13 PM, Scott Marlowe wrote:
>> The largest consequence I can see at the moment is that when I get a
>> full vacuum (for preventing transaction-id wraparound) it would be
>
> I assume you mean the automatic database wide vacuum. I don't think
> 8.4 and above need that any
Your response somehow landed in the subject line, apparently
truncated. I'll extract that to the message body and reply to what
made it through.
Rajesh Kumar Mallah wrote:
> Firstly many thanks for responding. I am concerned because the
> load averages have increased and users complaining of
On 6/23/10, Kevin Grittner wrote:
> Rajesh Kumar Mallah wrote:
>> PasteBin for the vmstat output
>> http://pastebin.com/mpHCW9gt
>>
>> On Wed, Jun 23, 2010 at 8:22 PM, Rajesh Kumar Mallah
>> wrote:
>>> Dear List ,
>>>
>>> I observe that my postgresql (ver 8.4.2) dedicated server has
>>> turned c
Anj Adu wrote:
> The combination index works great. Would adding the combination
> index guarantee that the optimizer will choose that index for
> these kind of queries involving the columns in the combination. I
> verified a couple of times and it picked the right index. Just
> wanted to make s
The combination index works great. Would adding the combination index
guarantee that the optimizer will choose that index for these kind of
queries involving the columns in the combination. I verified a couple
of times and it picked the right index. Just wanted to make sure it
does that consistentl
Rajesh Kumar Mallah wrote:
> PasteBin for the vmstat output
> http://pastebin.com/mpHCW9gt
>
> On Wed, Jun 23, 2010 at 8:22 PM, Rajesh Kumar Mallah
> wrote:
>> Dear List ,
>>
>> I observe that my postgresql (ver 8.4.2) dedicated server has
>> turned cpu bound and there is a high load average in
PasteBin for the vmstat output
http://pastebin.com/mpHCW9gt
On Wed, Jun 23, 2010 at 8:22 PM, Rajesh Kumar Mallah
wrote:
> Dear List ,
>
> I observe that my postgresql (ver 8.4.2) dedicated server has turned cpu
> bound and there is a high load average in the server > 50 usually.
> The server has
On Wed, Jun 23, 2010 at 6:06 AM, Ivan Voras wrote:
> On 06/22/10 16:40, Greg Smith wrote:
>> Grzegorz Jaśkiewicz wrote:
>>> raid: serveRAID M5014 SAS/SATA controller
>>>
>>
>> Do the "performant servers" have a different RAID card? This one has
>> terrible performance, and could alone be the sour
On Wed, Jun 23, 2010 at 8:25 AM, Ivan Voras wrote:
> On 06/23/10 14:00, Florian Weimer wrote:
>> * Ivan Voras:
>>
>>> On the other hand, RAID10 is simple enough that soft-RAID
>>> implementations should be more than adequate - any ideas why a dedicated
>>> card has it "slow"?
>>
>> Barrier support
On Wed, 23 Jun 2010, Ivan Voras wrote:
On 06/23/10 14:00, Florian Weimer wrote:
Barrier support on RAID10 seems to require some smallish amount of
non-volatile storage which supports a high number of write operations
per second, so a software-only solution might not be available.
If I understa
On 06/23/10 14:00, Florian Weimer wrote:
> * Ivan Voras:
>
>> On the other hand, RAID10 is simple enough that soft-RAID
>> implementations should be more than adequate - any ideas why a dedicated
>> card has it "slow"?
>
> Barrier support on RAID10 seems to require some smallish amount of
> non-v
* Ivan Voras:
> On the other hand, RAID10 is simple enough that soft-RAID
> implementations should be more than adequate - any ideas why a dedicated
> card has it "slow"?
Barrier support on RAID10 seems to require some smallish amount of
non-volatile storage which supports a high number of write
Craig, Russel,
I appreciate your help.
Thanks.
2010/6/22 Russell Smith
> On 22/06/10 00:42, Sergio Charpinel Jr. wrote:
> > Hi,
> >
> [snip]
> >
> > => explain analyze SELECT ip_src, port_src, ip_dst, port_dst,
> > tcp_flags, ip_proto,SUM("bytes"),SUM("packets"),SUM("flows") FROM
> > "acct_201
On 06/22/10 16:40, Greg Smith wrote:
> Grzegorz Jaśkiewicz wrote:
>> raid: serveRAID M5014 SAS/SATA controller
>>
>
> Do the "performant servers" have a different RAID card? This one has
> terrible performance, and could alone be the source of your issue. The
> ServeRAID cards are slow in gen
27 matches
Mail list logo
