Re: [PERFORM] Query about index usage

2010-06-23 Thread Greg Smith
Jayadevan M wrote: It is mentioned that table data blocks have data about tuple visibility and hence table scans are always necessary. So how does PostgreSQL reduce the number of blocks to be read by using indexes? To be useful, a query utilizing an index must be selective: it must only

Re: [PERFORM] Query about index usage

2010-06-23 Thread Jayadevan M
Thank you for the detailed explanation. Regards, Jayadevan DISCLAIMER: The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly

Re: [PERFORM] raid10 write performance

2010-06-23 Thread Ivan Voras
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 general, and

Re: [PERFORM] Low perfomance SUM and Group by large databse

2010-06-23 Thread Sergio Charpinel Jr.
Craig, Russel, I appreciate your help. Thanks. 2010/6/22 Russell Smith mr-r...@pws.com.au 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

Re: [PERFORM] raid10 write performance

2010-06-23 Thread Florian Weimer
* 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

Re: [PERFORM] raid10 write performance

2010-06-23 Thread Ivan Voras
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-volatile

Re: [PERFORM] raid10 write performance

2010-06-23 Thread Matthew Wakeling
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

Re: [PERFORM] raid10 write performance

2010-06-23 Thread Scott Marlowe
On Wed, Jun 23, 2010 at 8:25 AM, Ivan Voras ivo...@freebsd.org 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

Re: [PERFORM] raid10 write performance

2010-06-23 Thread Scott Marlowe
On Wed, Jun 23, 2010 at 6:06 AM, Ivan Voras ivo...@freebsd.org 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

Re: [PERFORM] cpu bound postgresql setup.

2010-06-23 Thread Kevin Grittner
Rajesh Kumar Mallah mallah.raj...@gmail.com wrote: PasteBin for the vmstat output http://pastebin.com/mpHCW9gt On Wed, Jun 23, 2010 at 8:22 PM, Rajesh Kumar Mallah mallah.raj...@gmail.com wrote: Dear List , I observe that my postgresql (ver 8.4.2) dedicated server has turned cpu bound

Re: [PERFORM] slow index lookup

2010-06-23 Thread Anj Adu
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

Re: [PERFORM] slow index lookup

2010-06-23 Thread Kevin Grittner
Anj Adu fotogra...@gmail.com 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

[PERFORM] Re: cpu bound postgresql setup. Firstly many thanks for responding. I am concerned because the load averages have increased and users complaining of slowness. I do not change settings freq

2010-06-23 Thread Rajesh Kumar Mallah
On 6/23/10, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Rajesh Kumar Mallah mallah.raj...@gmail.com wrote: PasteBin for the vmstat output http://pastebin.com/mpHCW9gt On Wed, Jun 23, 2010 at 8:22 PM, Rajesh Kumar Mallah mallah.raj...@gmail.com wrote: Dear List , I observe that my

Re: [PERFORM] cpu bound postgresql setup.

2010-06-23 Thread Kevin Grittner
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 mallah.raj...@gmail.com wrote: Firstly many thanks for responding. I am concerned because the load averages have increased and

Re: [PERFORM] Aggressive autovacuuming ?

2010-06-23 Thread Robert Haas
On Sun, Jun 20, 2010 at 4:13 PM, Scott Marlowe scott.marl...@gmail.com 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

Re: [PERFORM] Aggressive autovacuuming ?

2010-06-23 Thread Scott Marlowe
On Wed, Jun 23, 2010 at 1:58 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jun 20, 2010 at 4:13 PM, Scott Marlowe scott.marl...@gmail.com 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

Re: [PERFORM] Aggressive autovacuuming ?

2010-06-23 Thread Robert Haas
On Wed, Jun 23, 2010 at 2:20 PM, Scott Marlowe scott.marl...@gmail.com wrote: On Wed, Jun 23, 2010 at 1:58 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jun 20, 2010 at 4:13 PM, Scott Marlowe scott.marl...@gmail.com wrote: The largest consequence I can see at the moment is that when I

[PERFORM] WAL+Os on a single disk

2010-06-23 Thread Anj Adu
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

Re: [PERFORM] WAL+Os on a single disk

2010-06-23 Thread Scott Marlowe
On Wed, Jun 23, 2010 at 3:01 PM, Anj Adu fotogra...@gmail.com 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 .

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Bruce Momjian
Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com 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

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Bruce Momjian
Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com 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

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Pavel Stehule
2010/6/23 Bruce Momjian br...@momjian.us: Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com 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

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Bruce Momjian
Pavel Stehule wrote: 2010/6/23 Bruce Momjian br...@momjian.us: Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com writes: a) Eliminate WAL logging entirely If we elimiate WAL logging, that means a reinstall is required for even a

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Robert Haas
On Wed, Jun 23, 2010 at 3:37 PM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com writes: a) Eliminate WAL logging entirely If we elimiate WAL logging, that means a reinstall is required for even a

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Dave Page
On Wed, Jun 23, 2010 at 9:25 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 23, 2010 at 3:37 PM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com writes: a) Eliminate WAL logging entirely If we

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Bruce Momjian
Robert Haas wrote: On Wed, Jun 23, 2010 at 3:37 PM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: Josh Berkus j...@agliodbs.com writes: a) Eliminate WAL logging entirely If we elimiate WAL logging, that means a reinstall is

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Wed, Jun 23, 2010 at 9:25 PM, Robert Haas robertmh...@gmail.com 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

Re: [PERFORM] PostgreSQL as a local in-memory cache

2010-06-23 Thread Bruce Momjian
Tom Lane wrote: Dave Page dp...@pgadmin.org writes: On Wed, Jun 23, 2010 at 9:25 PM, Robert Haas robertmh...@gmail.com 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