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
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
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
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
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
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
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
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 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
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 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
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
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
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
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
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
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 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
"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, 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
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
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
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 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/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
> 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
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
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
> > 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.
* 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
30 matches
Mail list logo
