On Feb 13, 2008 12:46 PM, Kenneth Marshall [EMAIL PROTECTED] wrote:
On Wed, Feb 13, 2008 at 10:56:54AM -0600, Peter Koczan wrote:
Hi all,
We're considering setting up a SAN where I work. Is there anyone using
a SAN, for postgres or other purposes? If so I have a few questions
for you.
On 7/11/07, Andreas Kretschmer [EMAIL PROTECTED] wrote:
Hi,
Okay, i know, not really a recent version:
PostgreSQL 8.1.4 on i386-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5 (Debian
1:3.3.5-13)
I have a fresh ANALYZED table with some indexes.
scholl=*# set enable_bitmapscan=1;
SET
scholl=*#
On 7/11/07, A. Kretschmer [EMAIL PROTECTED] wrote:
am Wed, dem 11.07.2007, um 14:52:01 -0400 mailte Alex Deucher folgendes:
Okay, i got a really different plan, but i expected _NOT_ a
performance-boost like this. I expected the opposite.
It's not a really problem, i just played
On 7/11/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 7/11/07, A. Kretschmer [EMAIL PROTECTED] wrote:
am Wed, dem 11.07.2007, um 14:52:01 -0400 mailte Alex Deucher folgendes:
Okay, i got a really different plan, but i expected _NOT_ a
performance-boost like this. I expected the opposite
On 4/6/07, Michael Fuhr [EMAIL PROTECTED] wrote:
On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
onto 8.2, both have locale set to C. 8.2 seems to prefer Seq Scans
for the first query while the ordering
On 4/9/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/6/07, Michael Fuhr [EMAIL PROTECTED] wrote:
On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
onto 8.2, both have locale set to C. 8.2 seems to prefer Seq
On 4/9/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/9/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/6/07, Michael Fuhr [EMAIL PROTECTED] wrote:
On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
onto 8.2
One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
onto 8.2, both have locale set to C. 8.2 seems to prefer Seq Scans
for the first query while the ordering in the second query seems to
perform worse on 8.2. I ran analyze. I've tried with the encoding
set to UTF-8 and
On 4/6/07, Michael Fuhr [EMAIL PROTECTED] wrote:
On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
onto 8.2, both have locale set to C. 8.2 seems to prefer Seq Scans
for the first query while the ordering
Ok, well, I dropped the DB and reloaded it and now all seems to be
fine and performing well. I'm not sure what was going on before.
Thanks for everyone's help!
Alex
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED
On 4/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Apr 5, 2007, at 4:09 AM, Ron wrote:
BE VERY WARY OF USING AN ADAPTEC RAID CONTROLLER!
Thanks - I received similar private emails with the same advice. I
will change the controller to a LSI MegaRAID SAS 8408E -- any
feedback on this
On 4/5/07, Erik Jones [EMAIL PROTECTED] wrote:
On Apr 5, 2007, at 1:22 PM, Xiaoning Ding wrote:
Erik Jones wrote:
On Apr 5, 2007, at 12:09 PM, Xiaoning Ding wrote:
Hi,
A page may be double buffered in PG's buffer pool and in OS's buffer cache.
Other DBMS like DB2 and Oracle has provided
On 4/5/07, Xiaoning Ding [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On 4/5/07, Erik Jones [EMAIL PROTECTED] wrote:
On Apr 5, 2007, at 1:22 PM, Xiaoning Ding wrote:
Erik Jones wrote:
On Apr 5, 2007, at 12:09 PM, Xiaoning Ding wrote:
Hi,
A page may be double buffered in PG's buffer pool
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] writes:
and here are the query plans referenced in my last email (apologies if
you get these twice, they didn't seem to go through the first time,
perhaps due to size?). I cut out the longer ones.
The first case
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] writes:
and here are the query plans referenced in my last email (apologies if
you get these twice, they didn't seem to go through the first time,
perhaps due
On 4/3/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127138,AB7124531,AB7124513,AB7123427,AB7121183,AB7121036,AB7110101,AB7100321,AB7089845,AB7088750,AB7031384,AB7021188
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/3/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127138,AB7124531,AB7124513,AB7123427,AB7121183,AB7121036,AB7110101
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
On 4/3/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 4/3/07, Alex Deucher [EMAIL PROTECTED] wrote:
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127138
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] writes:
Turning off bitmapscan ends up doing a sequential scan. Turning off
both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
seem to want to use the index at all. Any ideas?
The ORed
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] writes:
Turning off bitmapscan ends up doing a sequential scan. Turning off
both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
seem to want to use the index at all. Any ideas?
The ORed
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] writes:
Turning off bitmapscan ends up doing a sequential scan. Turning off
both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
seem to want to use the index at all. Any ideas?
The ORed
Sorry if anyone receives this twice; it didn't seem to go through the
first time. I'll attach the query plans to another email in case they
were causing a size limit problem. Also here's the here's the table
description:
Table public.t1
Column | Type | Modifiers
and here are the query plans referenced in my last email (apologies if
you get these twice, they didn't seem to go through the first time,
perhaps due to size?). I cut out the longer ones.
Thanks,
Alex
postgres 7.4
EXPLAIN ANALYZE select num, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10,
c11 from
On 3/5/07, Guido Neitzer [EMAIL PROTECTED] wrote:
On 05.03.2007, at 19:56, Alex Deucher wrote:
Yes, I started setting that up this afternoon. I'm going to test that
tomorrow and post the results.
Good - that may or may not give some insight in the actual
bottleneck. You never know
On 3/6/07, Ron [EMAIL PROTECTED] wrote:
At 10:25 AM 3/6/2007, Alex Deucher wrote:
On 3/5/07, Guido Neitzer [EMAIL PROTECTED] wrote:
On 05.03.2007, at 19:56, Alex Deucher wrote:
Yes, I started setting that up this afternoon. I'm going to test that
tomorrow and post the results.
Good
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 on local scsi discs. The new server is a sun
Opteron box
On 3/5/07, Guido Neitzer [EMAIL PROTECTED] wrote:
On 01.03.2007, at 13:40, Alex Deucher wrote:
I read several places that the SAN might be to blame, but
testing with bonnie and dd indicates that the SAN is actually almost
twice as fast as the scsi discs in the old sun server. I've tried
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
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
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
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 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
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
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
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 on local scsi discs. The new server is a sun
Opteron box
On 3/1/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
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
On 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Joshua D. Drake wrote:
Alex Deucher wrote:
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 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:
Vacuum? Analayze? default_statistics_target? How many shared_buffers?
effective_cache_size? work_mem?
I'm running the autovacuum process on the 8.1 server. vacuuming on
the old server was done manually
On 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:
On 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:
Vacuum? Analayze? default_statistics_target? How many shared_buffers?
effective_cache_size? work_mem?
I'm
On 3/1/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
\
Is the SAN being shared between the database servers and other
servers? Maybe
it was just random timing that gave you the poor write performance on
the old
server which might be also yielding occassional poor performance on
the new
On 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:
On 3/1/07, Jeff Frost [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:
Postgresql might be choosing a bad plan because your
effective_cache_size
is
way off (it's the default now
On 3/1/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On 3/1/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
\
Is the SAN being shared between the database servers and other
servers? Maybe
it was just random timing that gave you the poor write performance on
the old
42 matches
Mail list logo
