* 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 mo
> > 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'r
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 c
> 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/sec
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 r
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 *GB
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 fro
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 an
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
"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 fo
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
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_xlo
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 Sol
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
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 f
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 k
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
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 configurat
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 jus
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 in
Bruce Momjian wrote:
> Sorry, I introduced this bug.
To the gallows with you! :) Don't feel bad, there were several hackers
that missed the math on that one.
Joshua D. Drake
>
> ---
>
> Tom Lane wrote:
>> Benjamin Minsha
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 sa
Abu,
> I really do not know how to find out what the query is waiting on,
> unlike oracle db provides some of the information through its dynamic
> performance views.
Yeah, we don't have that yet.
> Please help in understanding how I can find out what the system is
> waiting for or why is it
Josh Berkus writes:
>> Please help in understanding how I can find out what the system is
>> waiting for or why is it taking the query so long.
> First guess would be I/O bound. The planner, at least, thinks you're
> inserting 2 million records. What kind of disk support do you have?
I don't
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 of
30 matches
Mail list logo
