I think RAID 10 is best among all the RAID Levels.
Thanks
Craig Ringer wrote:
On 04/08/11 11:42, Jayadevan M wrote:
Hello,
>The most important spec has been omitted. What's the storage subsystem?
We have storage on SAN, RAID 5.
RAID 5? That's *really* not ideal for database workloads, eit
On 04/08/11 11:42, Jayadevan M wrote:
> Hello,
>
> >The most important spec has been omitted. What's the storage subsystem?
> We have storage on SAN, RAID 5.
RAID 5? That's *really* not ideal for database workloads, either Pg or
Oracle, unless your RAID 5 storage backend has enough battery-backed
Dear all,
From the last few days, I researched a lot on Postgresql Performance
Tuning due to slow speed of my server.
My application selects data from mysql database about 10 rows ,
process it & insert into postgres 2 tables by making about 45 connections.
I set my postgresql parameters i
Hello,
>The most important spec has been omitted. What's the storage subsystem?
We have storage on SAN, RAID 5.
> > We are suing weblogic.
> ^
> Best. Typo. Ever.
>
> I hear most people who use it want to, you're just brave enough to do it
:-P
I wish I could make a few millions
On Wed, Aug 3, 2011 at 6:24 PM, Merlin Moncure wrote:
> On Wed, Aug 3, 2011 at 2:18 AM, Robert Klemme
> wrote:
Another observation: That criterion looks suspicious to me. I would
expect any RDBMS to be better able to optimize this:
WHERE firstname = 'Eddie' AND lastname like '
Dusan Misic wrote:
> My question is simple. Does PostgreSQL perform better on Linux
> than on Windows and how much is it faster in your tests?
We tested this quite a while back (on 8.0 and 8.1) with identical
hardware and identical databases running in matching versions of
PostgreSQL. On both
Thank you Andy for your answer.
That is exactly what I had expected, but it is better to consult with
experts on this matter.
Again, thank you.
Dusan
On Aug 3, 2011 7:05 PM, "Andy Colson" wrote:
> On 8/3/2011 11:37 AM, Dusan Misic wrote:
>> I had done some testing for my application (WIP) and
On Wed, Aug 3, 2011 at 3:27 PM, Li Jin wrote:
> Robert，
> I've built an index on this expression firstname || ' ' ||
> substring(lastname,1,1). I believe this is the best index for this
> particular query. Correct me if I am wrong.
Maybe, maybe not. Difficult to tell from a distance. I would ha
On 8/3/2011 11:37 AM, Dusan Misic wrote:
I had done some testing for my application (WIP) and I had executed same
SQL script and queries on real physical 64-bit Windows 7 and on
virtualized 64-bit CentOS 6.
Both database servers are tuned with real having 8 GB RAM and 4 cores,
virtualized having
I had done some testing for my application (WIP) and I had executed same SQL
script and queries on real physical 64-bit Windows 7 and on virtualized
64-bit CentOS 6.
Both database servers are tuned with real having 8 GB RAM and 4 cores,
virtualized having 2 GB RAM and 2 virtual cores.
Virtualized
On Wed, Aug 3, 2011 at 2:18 AM, Robert Klemme
wrote:
>>> Another observation: That criterion looks suspicious to me. I would
>>> expect any RDBMS to be better able to optimize this:
>>>
>>> WHERE firstname = 'Eddie' AND lastname like 'T%'
>>>
>>> I know it's semantically not the same but I would a
On Wed, Aug 3, 2011 at 3:27 PM, Li Jin wrote:
> Robert，
> I've built an index on this expression firstname || ' ' ||
> substring(lastname,1,1). I believe this is the best index for this
> particular query. Correct me if I am wrong.
Maybe, maybe not. Difficult to tell from a distance. I would ha
On Fri, Jul 8, 2011 at 9:33 PM, Clem Dickey wrote:
> a. The Join cost estimators could have been given more information
>
> The functions which estimate JOIN selectivity (e.g. the chance that tuples
> will match in an equijoin, for instance) use data produced by ANALYZE. But
> the SELECT .. GROUP
On Tue, Aug 2, 2011 at 11:48 PM, Merlin Moncure wrote:
> On Sat, Jul 30, 2011 at 8:10 AM, Robert Klemme
> wrote:
>> On Thu, Jul 28, 2011 at 11:00 PM, Li Jin wrote:
>>> I met with the problem that when I was using WITH clause to reuse a
>>> subquery, I got a huge performance penalty because of qu
14 matches
Mail list logo
