Re: Is There Any Way .... - Mailing list pgsql-performance

A blast from the past is forwarded below.


    douglas


Begin forwarded message:


<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Tom Lane <<tgl@sss.pgh.pa.us>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>August
23, 2005 3:23:43 PM EDT

<bold><color><param>0000,0000,0000</param>To: </color></bold>Donald
Courtney <<Donald.Courtney@sun.com>

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>pgsql-performance@postgresql.org, Frank Wiles
<<frank@wiles.org>, gokulnathbabu manoharan <<gokulnathbabu@yahoo.com>

<bold><color><param>0000,0000,0000</param>Subject: </color>Re:
[PERFORM] Caching by Postgres

</bold>

Donald Courtney <<Donald.Courtney@Sun.COM> writes:

<excerpt>I am not alone in having the *expectation* that a database
should have

some cache size parameter and the option to skip the file system.  If

I use oracle, sybase, mysql and maxdb they all have the ability to

size a data cache and move to 64 bits.

</excerpt>

And you're not alone in holding that opinion despite having no shred

of evidence that it's worthwhile expanding the cache that far.


However, since we've gotten tired of hearing this FUD over and over,

8.1 will have the ability to set shared_buffers as high as you want.

I expect next we'll be hearing from people complaining that they

set shared_buffers to use all of RAM and performance went into the

tank ...


            regards, tom lane

</excerpt>


On Oct 4, 2005, at 11:06 PM, Ron Peacetree wrote:


<excerpt>Unfortunately, no matter what I say or do, I'm not going to
please

or convince anyone who has already have made their minds up

to the extent that they post comments like Mr Trainor's below.

His response style pretty much proves my earlier point that this

is presently a religious issue within the pg community.


The absolute best proof would be to build a version of pg that does

what Oracle and DB2 have done and implement it's own DB

specific memory manager and then compare the performance

between the two versions on the same HW, OS, and schema.


The second best proof would be to set up either DB2 or Oracle so

that they _don't_ use their memory managers and compare their

performance to a set up that _does_ use said memory managers

on the same HW, OS, and schema.


I don't currently have the resources for either experiment.


Some might even argue that IBM (where Codd and Date worked)

and Oracle just _might_ have had justification for the huge effort

they put into developing such infrastructure.


Then there's the large library of research on caching strategies

in just about every HW and SW domain, including DB theory,

that points put that the more context dependent, ie application

or domain specific awareness, caching strategies are the better

they are.


Maybe after we do all we can about physical IO and sorting

performance I'll take on the religious fanatics on this one.


One problem set at a time.

Ron

</excerpt>
A blast from the past is forwarded below.

     douglas

Begin forwarded message:

> From: Tom Lane <tgl@sss.pgh.pa.us>
> Date: August 23, 2005 3:23:43 PM EDT
> To: Donald Courtney <Donald.Courtney@sun.com>
> Cc: pgsql-performance@postgresql.org, Frank Wiles <frank@wiles.org>,
> gokulnathbabu manoharan <gokulnathbabu@yahoo.com>
> Subject: Re: [PERFORM] Caching by Postgres
>
> Donald Courtney <Donald.Courtney@Sun.COM> writes:
>> I am not alone in having the *expectation* that a database should have
>> some cache size parameter and the option to skip the file system.  If
>> I use oracle, sybase, mysql and maxdb they all have the ability to
>> size a data cache and move to 64 bits.
>
> And you're not alone in holding that opinion despite having no shred
> of evidence that it's worthwhile expanding the cache that far.
>
> However, since we've gotten tired of hearing this FUD over and over,
> 8.1 will have the ability to set shared_buffers as high as you want.
> I expect next we'll be hearing from people complaining that they
> set shared_buffers to use all of RAM and performance went into the
> tank ...
>
>             regards, tom lane


On Oct 4, 2005, at 11:06 PM, Ron Peacetree wrote:

> Unfortunately, no matter what I say or do, I'm not going to please
> or convince anyone who has already have made their minds up
> to the extent that they post comments like Mr Trainor's below.
> His response style pretty much proves my earlier point that this
> is presently a religious issue within the pg community.
>
> The absolute best proof would be to build a version of pg that does
> what Oracle and DB2 have done and implement it's own DB
> specific memory manager and then compare the performance
> between the two versions on the same HW, OS, and schema.
>
> The second best proof would be to set up either DB2 or Oracle so
> that they _don't_ use their memory managers and compare their
> performance to a set up that _does_ use said memory managers
> on the same HW, OS, and schema.
>
> I don't currently have the resources for either experiment.
>
> Some might even argue that IBM (where Codd and Date worked)
> and Oracle just _might_ have had justification for the huge effort
> they put into developing such infrastructure.
>
> Then there's the large library of research on caching strategies
> in just about every HW and SW domain, including DB theory,
> that points put that the more context dependent, ie application
> or domain specific awareness, caching strategies are the better
> they are.
>
> Maybe after we do all we can about physical IO and sorting
> performance I'll take on the religious fanatics on this one.
>
> One problem set at a time.
> Ron