A few quick random observations on the Xeon v. Opteron comparison:
- running a dual Xeon with hyperthreading turned on really isn't the
same as having a quad cpu system. I haven't seen postgresql specific
benchmarks, but the general case has been that HT is a benefit in a few
particular work
Nichlas =?iso-8859-1?Q?L=F6fdahl?= <[EMAIL PROTECTED]> writes:
> My question is, why doesn't the planner pick the same plan for Q1 & Q3?
I think it's mostly that after you've added and ANALYZEd the "age"
column, the planner has a pretty good idea of how many rows will pass
the "age > 17 AND age <
please ignore if this goes through. They've been bouncing and I'm trying to
find out why.
-m
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hello!
I'm using Postgres 7.4.5, sort_mem is 8192. Tables analyzed / vacuumed.
Here's a function I'm using to get an age from the user's birthday:
agey(date) -> SELECT date_part('year', age($1::timestamp))
The problem is, why do the plans differ so much between Q1 & Q3 below? Something with
a
Hi,
(pg_version 7.4.2, i do run vacuum analyze on the whole database frequently
and just before executing statements below)
i dont know if anyone can help me because i dont know really where the problem
is, but i try. If any further information is needed i'll be glad to send.
my real rule much
Bill,
> I'd be thrilled to test it too, if for no other reason that to determine
> whether what I'm experiencing really is the "CS problem".
Hmmm ... Gavin's patch is built against 8.0, and any version of the patch
would require linux 2.6, probably 2.6.7 minimum. Can you test on that linux
ve
Bill Montgomery wrote:
All,
I realize the excessive-context-switching-on-xeon issue has been
discussed at length in the past, but I wanted to follow up and verify my
conclusion from those discussions:
On a 2-way or 4-way Xeon box, there is no way to avoid excessive
(30,000-60,000 per second) co
Thanks for the helpful response.
Josh Berkus wrote:
First off, the good news: Gavin Sherry and OSDL may have made some
progress
on this. We'll be testing as soon as OSDL gets the Scalable Test Platform
running again. If you have the CS problem (which I don't think you do, see
below) and a t
Bill,
> I realize the excessive-context-switching-on-xeon issue has been
> discussed at length in the past, but I wanted to follow up and verify my
> conclusion from those discussions:
First off, the good news: Gavin Sherry and OSDL may have made some progress
on this. We'll be testing as soo
Patrick,
First off, thanks for posting this solution! I love to see a new demo of The
Power of Postgres(tm) and have been wondering about this particular problem
since it came up on IRC.
> The array method works quite nicely, especially for the
> columns like "languages" and "seeking" that are
All,
I realize the excessive-context-switching-on-xeon issue has been
discussed at length in the past, but I wanted to follow up and verify my
conclusion from those discussions:
On a 2-way or 4-way Xeon box, there is no way to avoid excessive
(30,000-60,000 per second) context switches when usi
> I don't know what you are exactly referring to in above URL
> when you are talking about "potential pitfalls of pooling".
> Please explain more.
Sorry, I wasn't implying that pgpool doesn't deal with the issues, just that
some people aren't necessarily aware of them up front. For instance, p
12 matches
Mail list logo
