* Alex Deucher:
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB).
Sorry for asking, but is this a typo? Do you mean 16 *TB* instead of
16 *GB*?
If it's really 16 GB, you should check if it's cheaper to buy
And this is the actual query:
I think you need to look into full-text indexing (see tsearch2).
Thanks, Tom.
Yes, we know this.
This is just a temporary fix that we needed to get up today for biz
reasons. Implementing full-text searching within a few short hours was
out of the question.
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On 3/2/07, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I think this explains the trigger that was blowing up my FC4 box.
I dug in the archives a bit and couldn't find the report you're
referring to?
I
Florian Weimer wrote:
* Alex Deucher:
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB).
Sorry for asking, but is this a typo? Do you mean 16 *TB* instead of
16 *GB*?
If it's really 16 GB, you should
From: Kris Kennaway [EMAIL PROTECTED]
We have recently made significant progress on optimizing for MySQL
running on an 8-core amd64 system. The graph of results may be found
here:
http://www.freebsd.org/~kris/scaling/scaling.png
This shows the graph of MySQL transactions/second
On 3/2/07, Florian Weimer [EMAIL PROTECTED] wrote:
* Alex Deucher:
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB).
Sorry for asking, but is this a typo? Do you mean 16 *TB* instead of
16 *GB*?
If it's
At 08:56 AM 3/2/2007, Carlos Moreno wrote:
Florian Weimer wrote:
* Alex Deucher:
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB).
Sorry for asking, but is this a typo? Do you mean 16 *TB* instead of
16
On 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:
here are some examples. Analyze is still running on the new db, I'll
post results when that is done. Mostly what our apps do is prepared
row selects from different tables:
select c1,c2,c3,c4,c5 from t1
At 10:16 AM 3/2/2007, Alex Deucher wrote:
On 3/2/07, Florian Weimer [EMAIL PROTECTED] wrote:
* Alex Deucher:
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB).
Sorry for asking, but is this a typo? Do you
Alvaro Herrera wrote:
Interesting -- the MySQL/Linux graph is very similar to the graphs from
the .nl magazine posted last year. I think this suggests that the
MySQL deficiency was rather a performance bug in Linux, not in MySQL
itself ...
The latest benchmark we did was both with Solaris and
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
At 10:16 AM 3/2/2007, Alex Deucher wrote:
On 3/2/07, Florian Weimer [EMAIL PROTECTED] wrote:
* Alex Deucher:
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB).
Sorry
Alex Deucher [EMAIL PROTECTED] writes:
Anyway, new numbers after the analyze.
Unfortunately, they are improved, but still not great:
Why are the index names different between the old and new servers?
Is that just cosmetic, or is 8.2 actually picking a different
(and less suitable) index for the
On 3/2/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] writes:
Anyway, new numbers after the analyze.
Unfortunately, they are improved, but still not great:
Why are the index names different between the old and new servers?
Is that just cosmetic, or is 8.2 actually
On Fri, 2007-03-02 at 09:01, Alvaro Herrera wrote:
From: Kris Kennaway [EMAIL PROTECTED]
We have recently made significant progress on optimizing for MySQL
running on an 8-core amd64 system. The graph of results may be found
here:
http://www.freebsd.org/~kris/scaling/scaling.png
On Fri, 2007-03-02 at 10:03, Alex Deucher wrote:
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
At 10:16 AM 3/2/2007, Alex Deucher wrote:
d= you went from local HD IO to a SAN
(many differences hidden in that one line... ...and is the physical
layout of tables and things like pg_xlog sane on
At 11:03 AM 3/2/2007, Alex Deucher wrote:
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
May I suggest that it is possible that your schema, queries, etc were
all optimized for pg 7.x running on the old HW?
(explain analyze shows the old system taking ~1/10 the time per row
as well as estimating the
Am Donnerstag 01 März 2007 21:44 schrieb Alex Deucher:
Hello,
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB). The
original postgres 7.4 was running on a sun v880 with 4 CPUs and 8 GB
of ram running Solaris
Florian Weimer escribió:
Locale settings make a huge difference for sorting and LIKE queries.
We usually use the C locale and SQL_ASCII encoding, mostly for
performance reasons. (Proper UTF-8 can be enforced through
constraints if necessary.)
Hmm, you are aware of varchar_pattern_ops and
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
At 11:03 AM 3/2/2007, Alex Deucher wrote:
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
May I suggest that it is possible that your schema, queries, etc were
all optimized for pg 7.x running on the old HW?
(explain analyze shows the old system taking ~1/10 the
On Thu, 2007-03-01 at 19:59 -0800, Adam L Beberg wrote:
On the surface, looks like a job for GIN, but GIN seems undocumented,
specifically mentions it doesn't support the deletes we'll have many of
since it's designed for word searching apparently, the performance
It can delete an entry for
At 02:43 PM 3/2/2007, Alex Deucher wrote:
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
...and I still think looking closely at the actual physical layout of
the tables in the SAN is likely to be worth it.
How would I go about doing that?
Alex
Hard for me to give specific advice when I don't
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
At 02:43 PM 3/2/2007, Alex Deucher wrote:
On 3/2/07, Ron [EMAIL PROTECTED] wrote:
...and I still think looking closely at the actual physical layout of
the tables in the SAN is likely to be worth it.
How would I go about doing that?
Alex
Hard for me to
On 02.03.2007, at 14:20, Alex Deucher wrote:
Ah OK. I see what you are saying; thank you for clarifying. Yes,
the SAN is configured for maximum capacity; it has large RAID 5
groups. As I said earlier, we never intended to run a DB on the SAN,
it just happened to come up, hence the
On Fri, 2 Mar 2007, Guido Neitzer wrote:
On 02.03.2007, at 14:20, Alex Deucher wrote:
Ah OK. I see what you are saying; thank you for clarifying. Yes,
the SAN is configured for maximum capacity; it has large RAID 5
groups. As I said earlier, we never intended to run a DB on the SAN,
it
Sorry, I introduced this bug.
---
Tom Lane wrote:
Benjamin Minshall [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's sounding like what you had was just transient bloat, in which case
it might be useful to inquire
On 3/2/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Fri, 2 Mar 2007, Guido Neitzer wrote:
On 02.03.2007, at 14:20, Alex Deucher wrote:
Ah OK. I see what you are saying; thank you for clarifying. Yes,
the SAN is configured for maximum capacity; it has large RAID 5
groups. As I said
Carlos Moreno skrev:
The system does very frequent insertions and updates --- the longest
table has, perhaps, some 20 million rows, and it's indexed (the primary
key is the combination of two integer fields). This longest table only
has inserts (and much less frequent selects), at a peak rate
27 matches
Mail list logo
