Re: [PERFORM] Hardware for PostgreSQL

Ow Mun Heng wrote: >> You're likely better off (performance-wise) putting it on the same disk >> as the database itself if that one has better RAID, for example. > > I'm thinking along the lines of since nothing much writes to the OS > Disk, I should(keyword) be safe. Unless it's *always* in the

Re: [PERFORM] Hardware for PostgreSQL

On Thu, 2007-11-01 at 07:54 +0100, Magnus Hagander wrote: > Ow Mun Heng wrote: > > On Wed, 2007-10-31 at 22:58 +0100, Tomas Vondra wrote: > > > >> 2) separate the transaction log from the database > >> > >> It's mostly written, and it's the most valuable data you have. And in > >> case yo

Re: [PERFORM] hardware and For PostgreSQL

Ron St-Pierre wrote: > Joe Uhl wrote: >> I realize there are people who discourage looking at Dell, but i've been >> very happy with a larger ball of equipment we ordered recently from >> them. Our database servers consist of a PowerEdge 2950 connected to a >> PowerVault MD1000 with a 1 meter SAS

Re: [PERFORM] Hardware for PostgreSQL

Ow Mun Heng wrote: > On Wed, 2007-10-31 at 22:58 +0100, Tomas Vondra wrote: > >> 2) separate the transaction log from the database >> >> It's mostly written, and it's the most valuable data you have. And in >> case you use PITR, this is the only thing that really needs to be >> backed

Re: [PERFORM] Hardware for PostgreSQL

Tomas Vondra wrote: >> How does pg utilize multiple processors? The more the better? > > Linux version uses processes, so it's able to use multiple processors. > (Not sure about Windows version, but I guess it uses threads.) No, the Windows version also uses processes. //Magnus -

Re: [PERFORM] Hardware for PostgreSQL

On Wed, 2007-10-31 at 22:58 +0100, Tomas Vondra wrote: > 2) separate the transaction log from the database > > It's mostly written, and it's the most valuable data you have. And in > case you use PITR, this is the only thing that really needs to be > backed up. My main DB datastore

Re: [PERFORM] Hardware for PostgreSQL

> > Who has built the biggest baddest Pg server out there and what do you > > use? In my last job we had a 360GB database running on a 8 way opteron with 32 Gigs of ram. Two of those beasts connected to a SAN for hot failover purposes. We did not have much web traffic, but tons of update/insert t

Re: [PERFORM] hardware and For PostgreSQL

Ron St-Pierre wrote: Joe Uhl wrote: I realize there are people who discourage looking at Dell, but i've been very happy with a larger ball of equipment we ordered recently from them. Our database servers consist of a PowerEdge 2950 connected to a PowerVault MD1000 with a 1 meter SAS cable.

Re: [Fwd: Re: [PERFORM] Outer joins and Seq scans]

Sami Dalouche <[EMAIL PROTECTED]> writes: > -- For some reason, my message doesn't seem to go through the mailing > list, so I am trying without any attachment Please don't do that, at least not that way. These explain outputs have been line-wrapped to the point of utter unreadability. The main

Re: [PERFORM] hardware and For PostgreSQL

On Wed, 31 Oct 2007 14:54:51 -0400 Joe Uhl <[EMAIL PROTECTED]> wrote: > I realize there are people who discourage looking at Dell, but i've > been very happy with a larger ball of equipment we ordered recently > from them. Our database servers consist of a PowerEdge 2950 > connected to a PowerVau

[Fwd: Re: [PERFORM] Outer joins and Seq scans]

-- For some reason, my message doesn't seem to go through the mailing list, so I am trying without any attachment Hi, Thank you Tom and Dimitri for your precious help. So, I applied the patch at http://archives.postgresql.org/pgsql-committers/2007-10/msg00374.php The good news is that with the

Re: [PERFORM] hardware and For PostgreSQL

Joe Uhl wrote: I realize there are people who discourage looking at Dell, but i've been very happy with a larger ball of equipment we ordered recently from them. Our database servers consist of a PowerEdge 2950 connected to a PowerVault MD1000 with a 1 meter SAS cable. We have a similar piec

Re: [PERFORM] Hardware for PostgreSQL

I understand query tuning and table design play a large role in performance, but taking that factor away and focusing on just hardware, what is the best hardware to get for Pg to work at the highest level (meaning speed at returning results)? Depends heavily on the particular application, but mo

Re: [PERFORM] Hardware for PostgreSQL

>>> On Wed, Oct 31, 2007 at 11:45 AM, in message <[EMAIL PROTECTED]>, Ketema <[EMAIL PROTECTED]> wrote: > Who has built the biggest baddest Pg server out there and what do you > use? I don't think that would be us, but I can give you an example of what can work. We have a 220 GB database whic

Re: [PERFORM] tables with 300+ partitions

Scott Marlowe wrote: On 10/31/07, Pablo Alcaraz <[EMAIL PROTECTED]> wrote: Steven Flatt wrote: On 10/30/07, Pablo Alcaraz <[EMAIL PROTECTED]> wrote: I did some testing. I created a 300 partitioned empty table. Then, I inserted some rows on it and the perfomance was SLOW too. I

Re: [PERFORM] hardware and For PostgreSQL

I realize there are people who discourage looking at Dell, but i've been very happy with a larger ball of equipment we ordered recently from them. Our database servers consist of a PowerEdge 2950 connected to a PowerVault MD1000 with a 1 meter SAS cable. The 2950 tops out at dual quad core cpus,

Re: [PERFORM] Hardware for PostgreSQL

On 31-10-2007 17:45 Ketema wrote: I understand query tuning and table design play a large role in performance, but taking that factor away and focusing on just hardware, what is the best hardware to get for Pg to work at the highest level (meaning speed at returning results)? It really depends

Re: [PERFORM] Hardware for PostgreSQL

Ketema wrote: > I am trying to build a very Robust DB server that will support 1000+ > concurrent users (all ready have seen max of 237 no pooling being > used). I have read so many articles now that I am just saturated. I > have a general idea but would like feedback from others. > > I understa

Re: [PERFORM] tables with 300+ partitions

On 10/31/07, Pablo Alcaraz <[EMAIL PROTECTED]> wrote: > > Steven Flatt wrote: > > On 10/30/07, Pablo Alcaraz <[EMAIL PROTECTED]> wrote: > > I did some testing. I created a 300 partitioned empty table. Then, I > > inserted some rows on it and the perfomance was SLOW too. > > > Is the problem with i

Re: [PERFORM] hardware and For PostgreSQL

It would probably help you to spend some time browsing the archives of this list for questions similar to yours - you'll find quite a lot of consistent answers. In general, you'll find that: - If you can fit your entire database into memory, you'll get the best performance. - If you cannot (

[PERFORM] Hardware for PostgreSQL

I am trying to build a very Robust DB server that will support 1000+ concurrent users (all ready have seen max of 237 no pooling being used). I have read so many articles now that I am just saturated. I have a general idea but would like feedback from others. I understand query tuning and table

Re: [PERFORM] tables with 300+ partitions

> Steven Flatt wrote: >> On 10/30/07, *Pablo Alcaraz* <[EMAIL PROTECTED] >> > wrote: >> >> I did some testing. I created a 300 partitioned empty table. Then, I >> inserted some rows on it and the perfomance was SLOW too. >> >> Is the problem with inserting to the

Re: [PERFORM] tables with 300+ partitions

On 10/31/07, Pablo Alcaraz <[EMAIL PROTECTED]> wrote: > > I was a program inserting into the base table. The program ran in 200+ > threads and every thread insert data on it. Every thread inserts a row every > 3 seconds aprox.(or they used to do it), but when I put more partitions the > insert spee

Re: [PERFORM] hardware and For PostgreSQL

On 10/31/07, Ketema Harris <[EMAIL PROTECTED]> wrote: > I am trying to build a very Robust DB server that will support 1000+ > concurrent users (all ready have seen max of 237 no pooling being > used). i have read so many articles now that I am just saturated. I > have a general idea but would li

[PERFORM] hardware and For PostgreSQL

I am trying to build a very Robust DB server that will support 1000+ concurrent users (all ready have seen max of 237 no pooling being used). i have read so many articles now that I am just saturated. I have a general idea but would like feedback from others. I understand query tuning and

Re: [PERFORM] tables with 300+ partitions

Steven Flatt wrote: On 10/30/07, *Pablo Alcaraz* <[EMAIL PROTECTED] > wrote: I did some testing. I created a 300 partitioned empty table. Then, I inserted some rows on it and the perfomance was SLOW too. Is the problem with inserting to the partitioned tabl

Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1

BTW - Mark has volunteered to work a Postgres patch together. Thanks Mark! - Luke On 10/29/07 10:46 PM, "Mark Kirkwood" <[EMAIL PROTECTED]> wrote: > Luke Lonergan wrote: >> Sure - it's here: >> http://momjian.us/mhonarc/patches_hold/msg00381.html >> >> > > To clarify - we've fixed this

Re: [PERFORM] Two fast queries get slow when combined

You are lying to us about how those queries were posed to Postgres (and no I don't feel a need to explain how I know). Sorry. The "lying" was not intended as explained in my reply to Heikku. Thanks for the tips anyways. ---(end of broadcast)--- T

Re: [PERFORM] Two fast queries get slow when combined

There's something odd about that plan. It's doing both a seq scan and a bitmap scan on "items", but I can't see stats table being mentioned anywhere. Huh? Aaah, sorry. I made a major search/replace-refactoring (that obviously went wrong) on all open files in the editor before posting to this

Re: [PERFORM] Optimizing PostgreSQL for Windows

Now the execution time for my query is down to ~10 - 13 seconds, which is already a big step ahead. Thanks! Are there any other settings that might be necessary to tweak on windows in order to reduce execution time even a little bit more? One thing i don't understand very well though is that if I e