In the query plan ..it uses seq scan rather than index scan .. why ? I
have index on lastname, firtname…
Have you run VACUUM ANALYZE; on the table recently?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Hi everybody..
Before anything else I would like to thank all those
person who answers my previous question… again thank you very much
This is my question …
In my query .. Select * from table1 where lastname LIKE
‘PUNCIA%’..
In the query plan ..it uses seq s
BM> see my other mail.
BM> We are running Linux, Kernel 2.4. As soon as the next debian version
BM> comes out, I'll happily switch to 2.6 :)
it's very simple to use 2.6 with testing version, but if you like
woody - you can simple install several packets from testing or
backports.org
if you thin
...and on Tue, May 11, 2004 at 03:02:24PM -0600, scott.marlowe used the keyboard:
>
> If you get the LSI megaraid, make sure you're running the latest megaraid
> 2 driver, not the older, slower 1.18 series. If you are running linux,
> look for the dkms packaged version. dkms, (Dynamic Kernel M
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> I am curious if there are any real life production quad processor setups
> running postgresql out there. Since postgresql lacks a proper
> replication/cluster solution, we have to buy a bigger machine.
Du you run the latest version of PG? I've read
Hi Paul,
Thanks for the valuable feedback. I suspect you're correct about the
serialization in some capacity, but the actual cause is eluding me.
Basically, every time a registered user checks a page, the site has to
authenticate them (with a query against a table with > 200,000 records). It
do
On Tue, 11 May 2004, Allan Wind wrote:
> On 2004-05-11T15:29:46-0600, scott.marlowe wrote:
> > The other nice thing about the LSI cards is that you can install >1 and
> > the act like one big RAID array. i.e. install two cards with a 20 drive
> > RAID0 then make a RAID1 across them, and if one
I'm confused why you say the system is 70% busy: the vmstat output
shows 70% *idle*.
The vmstat you sent shows good things and ambiguous things:
- si and so are zero, so your not paging/swapping. Thats always step
1. you're fine.
- bi and bo (physical IO) shows pretty high numbers for how many
On Tue, 2004-05-11 at 14:52, Paul Tuckfield wrote:
> Love that froogle.
>
> It looks like a nice card. One thing I didn't get straight is if
> the cache is writethru or write back.
The LSI MegaRAID reading/writing/caching behavior is user configurable.
It will support both write-back and wr
On Tue, 2004-05-11 at 12:06, Bjoern Metzdorf wrote:
> Has anyone experiences with quad Xeon or quad Opteron setups? I am
> looking at the appropriate boards from Tyan, which would be the only
> option for us to buy such a beast. The 30k+ setups from Dell etc. don't
> fit our budget.
>
> I am th
On 2004-05-11T15:29:46-0600, scott.marlowe wrote:
> The other nice thing about the LSI cards is that you can install >1 and
> the act like one big RAID array. i.e. install two cards with a 20 drive
> RAID0 then make a RAID1 across them, and if one or the other cards itself
> fails, you've still
Hi All,
We have a Postgres 7.4.1 server running on FreeBSD 5.2. Hardware is a Dual
Xeon 2.6 (HT enabled), 2 GB Memory, 3Ware SATA RAID-5 w/ 4 7200 RPM Seagate
disks and gigabit Intel Server Ethernet. The server is dedicated to serving
data to our web-based CMS.
We have a few web servers load ba
On Tue, 11 May 2004, Rob Sell wrote:
>
> If you don't mind slumming on ebay :-) keep an eye out for PERC III cards,
> they are dell branded LSI cards. Perc = Power Edge Raid Controller. There
> are models on there dual channel u320 and dell usually sells them with
> battery backed cache. That's
On Tue, 11 May 2004, Paul Tuckfield wrote:
> Love that froogle.
>
> It looks like a nice card. One thing I didn't get straight is if
> the cache is writethru or write back.
>
> If the original posters problem is truly a burst write problem (and not
> linux caching or virtual memory overcom
Hello,
I've been having some performance issues with a DB I use. I'm trying to
come up with some performance recommendations to send to the "adminstrator".
Hardware:
CPU0: Pentium III (Coppermine) 1000MHz (256k cache)
CPU1: Pentium III (Coppermine) 1000MHz (256k cache)
Memory: 3863468 kB (4 GB)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of scott.marlowe
Sent: Tuesday, May 11, 2004 2:23 PM
To: Paul Tuckfield
Cc: [EMAIL PROTECTED]; Matthew Nuzum; [EMAIL PROTECTED]; Rob
Fielding
Subject: Re: [PERFORM] Configuring PostgreSQL to minimize impact of
Love that froogle.
It looks like a nice card. One thing I didn't get straight is if
the cache is writethru or write back.
If the original posters problem is truly a burst write problem (and not
linux caching or virtual memory overcommitment) then writeback is key.
On Tue, 11 May 2004, P
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bjoern Metzdorf
Sent: Tuesday, May 11, 2004 3:11 PM
To: scott.marlowe
Cc: [EMAIL PROTECTED]; Pgsql-Admin (E-mail)
Subject: Re: [PERFORM] Quad processor options
scott.marlowe wrote:
>>Next drives I'll buy wil
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> scott.marlowe wrote:
> > Sure, adaptec makes one, so does lsi megaraid. Dell resells both of
> > these, the PERC3DI and the PERC3DC are adaptec, then lsi in that order, I
> > believe. We run the lsi megaraid with 64 megs battery backed cache.
>
>
scott.marlowe wrote:
Next drives I'll buy will certainly be 15k scsi drives.
Better to buy more 10k drives than fewer 15k drives. Other than slightly
faster select times, the 15ks aren't really any faster.
Good to know. I'll remember that.
In peak times we can get up to 700-800 connections at the
Anjan Dave wrote:
Did you mean to say the trigger-based clustering solution
> is loading the dual CPUs 60-70% right now?
No, this is without any triggers involved.
Performance will not be linear with more processors,
> but it does help with more processes.
> We haven't benchmarked it, but we have
Paul Tuckfield wrote:
Would you mind forwarding the output of "vmstat 10 120" under peak load
period? (I'm asusming this is linux or unix variant) a brief
description of what is happening during the vmstat sample would help a
lot too.
see my other mail.
We are running Linux, Kernel 2.4. As soo
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> scott.marlowe wrote:
>
> > Well, from what I've read elsewhere on the internet, it would seem the
> > Opterons scale better to 4 CPUs than the basic Xeons do. Of course, the
> > exception to this is SGI's altix, which uses their own chipset and run
Did you mean to say the trigger-based clustering solution is loading the dual CPUs
60-70% right now?
Performance will not be linear with more processors, but it does help with more
processes. We haven't benchmarked it, but we haven't had any problems also so far in
terms of performance.
Pric
scott.marlowe wrote:
Well, from what I've read elsewhere on the internet, it would seem the
Opterons scale better to 4 CPUs than the basic Xeons do. Of course, the
exception to this is SGI's altix, which uses their own chipset and runs
the itanium with very good memory bandwidth.
This is basica
Anjan Dave wrote:
We use XEON Quads (PowerEdge 6650s) and they work nice,
> provided you configure the postgres properly.
> Dell is the cheapest quad you can buy i think.
> You shouldn't be paying 30K unless you are getting high CPU-cache
> on each processor and tons of memory.
good to hear, I trie
On Tue, 11 May 2004, Paul Tuckfield wrote:
> If you are having a "write storm" or bursty writes that's burying
> performance, a scsi raid controler with writeback cache will greatly
> improve the situation, but I do believe they run around $1-2k. If
> it's write specific problem, the cache ma
it's very good to understand specific choke points you're trying to
address by upgrading so you dont get disappointed. Are you truly CPU
constrained, or is it memory footprint or IO thruput that makes you
want to upgrade?
IMO The best way to begin understanding system choke points is vmstat
o
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> Hi,
>
> I am curious if there are any real life production quad processor setups
> running postgresql out there. Since postgresql lacks a proper
> replication/cluster solution, we have to buy a bigger machine.
>
> Right now we are running on a dual
We use XEON Quads (PowerEdge 6650s) and they work nice, provided you configure the
postgres properly. Dell is the cheapest quad you can buy i think. You shouldn't be
paying 30K unless you are getting high CPU-cache on each processor and tons of memory.
I am actually curious, have you researched
The king of statistics in these cases, is probably vmstat. one can
drill down on specific things from there, but first you should send
some vmstat output.
Reducing cache -> reducing IO suggests to me the OS might be paging out
shared buffers. This is indicated by activity in the "si" and "so
Hi,
I am curious if there are any real life production quad processor setups
running postgresql out there. Since postgresql lacks a proper
replication/cluster solution, we have to buy a bigger machine.
Right now we are running on a dual 2.4 Xeon, 3 GB Ram and U160 SCSI
hardware-raid 10.
Has an
scott.marlowe wrote:
Sorry about that, I meant kbytes, not megs. My point being it's NOT
measured in 8k blocks, like a lot of other settings. sorry for the mixup.
No worries, I just wanted to sort that out for my own benefit, and
anyone else who may not have caught that.
On Tue, 11 May 2004 [EMAIL PROTECTED] wrote:
> Quoting Rob Fielding <[EMAIL PROTECTED]>:
>
> > Assuming you're running with optimal schema and index design (ie you're
> > not doing extra work unnecessarily), and your backend has
> > better-then-default config options set-up (plenty of tips arou
Quoting Rob Fielding <[EMAIL PROTECTED]>:
> Assuming you're running with optimal schema and index design (ie you're
> not doing extra work unnecessarily), and your backend has
> better-then-default config options set-up (plenty of tips around here),
> then disk arrangement is critical to smooth
Matthew Nuzum wrote:
Jack Orenstein <[EMAIL PROTECTED]> writes:
I'm looking at one case in which two successive transactions, each
updating a handful of records, take 26 and 18 *seconds* (not msec) to
complete. These transactions normally complete in under 30 msec.
None of this is necessarily goi
Jan Wieck <[EMAIL PROTECTED]> writes:
> If we would combine the background writer and the checkpointer,
... which in fact is on my agenda of things to do ...
> then a
> "checkpoint flush" could actually be implemented as a temporary change
> in that activity that basically is done by not reeval
>
> Jack Orenstein <[EMAIL PROTECTED]> writes:
> > I'm looking at one case in which two successive transactions, each
> > updating a handful of records, take 26 and 18 *seconds* (not msec) to
> > complete. These transactions normally complete in under 30 msec.
...
> None of this is necessarily go
38 matches
Mail list logo
