Hmmm...
I may be mistaken (I think last time I read about optimization params was in
7.3 docs), but doesn't RPC 1 mean that random read is faster than
sequential read? In your case, do you really think reading randomly is 4x
faster than reading sequentially? Doesn't seem to make sense, even with
Dear Gurus,
- Original Message -
From: Stephan Szabo [EMAIL PROTECTED]
Sent: Thursday, June 10, 2004 7:14 PM
On Thu, 10 Jun 2004, Stephan Szabo wrote:
On Thu, 10 Jun 2004, Jean-Luc Lachance wrote:
I agree, but it should be a simple rewrite. No?
It's NULLs inside the
by default -- do you mean there is a way to tell Linux to favor the second
real cpu over the HT one? how?
G.
--- cut here ---
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 6:26 PM
Subject:
A bit OT:
do regex ops (~, ~*) use index scan in non-C locales? Is it worth to
convert LIKE to regex?
G.
--- cut here ---
- Original Message -
From: Richard Huxton [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:40 PM
Check the
Alexandre,
I missed your orig. post, but AFAIK multiprocessing kernels will handle HT
CPUs as 2 CPUs each. Thus, our dual Xeon 2.4 is recognized as 4 Xeon 2.4
CPUs.
This way, I don't think HT would improve any single query (afaik no postgres
process uses more than one cpu), but overall
Fernando,
1. Try EXPLAIN ANALYZE. Cost alone isn't an absolute measure. I think it's
only to see which parts of the query are expected to be slowest. However,
EXP ANA will give you exact times in msec (which effectively means it
executes the query).
2. I think calling upper() for each row costs
