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 scan rather than
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
Yes , I already do that but the same result .. LIKE uses seq scan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Kings-Lynne
Sent: Wednesday, May 12, 2004 2:48 PM
To: Michael Ryan S. Puncia
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Using
Are you in a non-C locale?
Chris
Michael Ryan S. Puncia wrote:
Yes , I already do that but the same result .. LIKE uses seq scan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Kings-Lynne
Sent: Wednesday, May 12, 2004 2:48 PM
To: Michael
Sorry .. I am a newbie and I don't know :(
How can I know that I am in C locale ?
How can I change my database to use C locale?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Kings-Lynne
Sent: Wednesday, May 12, 2004 3:59 PM
To: Michael
Doug Y wrote:
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:
TL == Tom Lane [EMAIL PROTECTED] writes:
TL 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.
TL
JAR == J Andrew Rogers [EMAIL PROTECTED] writes:
JAR The LSI MegaRAID reading/writing/caching behavior is user configurable.
JAR It will support both write-back and write-through, and IIRC, three
JAR different algorithms for reading (none, read-ahead, adaptive). Plenty
JAR of configuration
Quoting Vivek Khera [EMAIL PROTECTED]:
TL == Tom Lane [EMAIL PROTECTED] writes:
TL 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
On May 12, 2004, at 3:22 PM, [EMAIL PROTECTED] wrote:
I don't see that. But I also set checkpoint segments to about 50 on
my big server.
But wouldn't that affect checkpoint frequency, not checkpoint cost
Seems reasonable. I suppose checkpointing doesn't cost as much disk
I/O as vacuum does.
On Tue, 11 May 2004 15:46:25 -0700, Paul Tuckfield [EMAIL PROTECTED]
wrote:
- the cache column shows that linux is using 2.3G for cache. (way too
much)
There is no such thing as way too much cache.
you generally want to give memory to postgres to keep it close to
the user,
Yes, but only a
On Wed, 12 May 2004, Grega Bremec wrote:
...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
Hi,
at first, many thanks for your valuable replies. On my quest for the
ultimate hardware platform I'll try to summarize the things I learned.
-
This is our current setup:
Hardware:
Dual Xeon DP 2.4 on a TYAN S2722-533 with HT enabled
13 matches
Mail list logo
