The hardware platform to deploy onto may well influence your choice :
Intel is usually the most cost effective , which means using Linux makes
sense in that case (anybody measured Pg performance on Solaris/Intel?).
If however, you are going to run a very "big in some sense" database,
then 6
Stalin,
> As anyone done benchmarking tests with postgres running on solaris and linux
> (redhat) assuming both environment has similar hardware, memory, processing
> speed etc. By reading few posts here, i can see linux would outperform
> solaris cause linux being very good at kernel caching than
Stalin,
> We are evaluating the options for having multiple databases vs. schemas on a
> single database cluster for a custom grown app that we developed. Each app
> installs same set of tables for each service. And the service could easily
> be in thousands. so Is it better to have 1000 databases
As anyone done benchmarking tests with postgres running on solaris and linux
(redhat) assuming both environment has similar hardware, memory, processing
speed etc. By reading few posts here, i can see linux would outperform
solaris cause linux being very good at kernel caching than solaris which is
"Subbiah, Stalin" <[EMAIL PROTECTED]> writes:
> Is it better to have 1000 databases vs 1000 schemas in a
> database cluster.
You almost certainly want to go for schemas, at least from a performance
point of view. The overhead of a schema is small (basically one more
row in pg_namespace) whereas t
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Well, you have to be careful on the combination to not give the wrong
> answers if there's a row with u.status=3 that matches a row d.status=3.
We could in theory handle that using something similar to the method
currently used for "OR" indexscans (that
Stephan Szabo wrote:
On Mon, 22 Mar 2004, Joseph Shraibman wrote:
Tom Lane wrote:
Joseph Shraibman <[EMAIL PROTECTED]> writes:
No, pkey is not the primary key in this case. The number of entries in u
that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be in
On Mon, 22 Mar 2004, Joseph Shraibman wrote:
> Tom Lane wrote:
> > Joseph Shraibman <[EMAIL PROTECTED]> writes:
> >
> >>No, pkey is not the primary key in this case. The number of entries in u
> >>that have pkey 260 and not boolfield is 344706.
> >
> >
> > ... and every one of those rows *must* b
Tom Lane wrote:
Joseph Shraibman <[EMAIL PROTECTED]> writes:
No, pkey is not the primary key in this case. The number of entries in u
that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be included in the join input,
*If* you use one big join in the first plac
Joseph Shraibman <[EMAIL PROTECTED]> writes:
> No, pkey is not the primary key in this case. The number of entries in u
> that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be included in the join input,
regardless of its status value, because it might join to
Richard Huxton wrote:
On Thursday 18 March 2004 21:21, Joseph Shraibman wrote:
explain
SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
AND (u.status = 3 OR d.status = 3 ) AND NOT u.boolfield ;
QUERY PLAN
--
[EMAIL PROTECTED] wrote:
> On 18 Mar, Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> >> 1) This is an OSS project. Why not just recruit a bunch of people on
> >> PERFORMANCE and GENERAL to test the 4 different synch methods using real
> >> databases? No test like reality, I say
[EMAIL PROTECTED] writes:
> I could certainly do some testing if you want to see how DBT-2 does.
> Just tell me what to do. ;)
Just do some runs that are identical except for the wal_sync_method
setting. Note that this should not have any impact on SELECT
performance, only insert/update/delete pe
On Thursday 18 March 2004 21:21, Joseph Shraibman wrote:
> explain
> SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
> AND (u.status = 3 OR d.status = 3 ) AND NOT u.boolfield ;
>
>
>QUERY PLAN
> --
explain
SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
AND (u.status = 3 ) AND NOT u.boolfield ;
QUERY PLAN
--
Aggregate (cost=45707.84..45
On Thu, Mar 18, 2004 at 02:22:10PM -0500, Bruce Momjian wrote:
>
> OK, what better test do you suggest? Right now, there has been no
> testing of these.
I suggest you start by doing atleast preallocating a 16 MB file
and do the tests on that, to atleast be somewhat simular to what
WAL does.
I h
On Thu, Mar 18, 2004 at 03:34:21PM -0500, Bruce Momjian wrote:
> Kurt Roeckx wrote:
> > Here are my results on Linux 2.6.1 using cvs version 1.7.
> >
> > Those times with > 20 seconds, you really hear the disk go crazy.
> >
> > And I have the feeling something must be wrong. Those results
> > ar
Here are my results on Linux 2.6.1 using cvs version 1.7.
Those times with > 20 seconds, you really hear the disk go crazy.
And I have the feeling something must be wrong. Those results
are reproducible.
Kurt
Simple write timing:
write0.139558
Compare fsync times
On Thu, Mar 18, 2004 at 01:50:32PM -0500, Bruce Momjian wrote:
> > I'm not sure I believe these numbers at all... my experience is that
> > getting trustworthy disk I/O numbers is *not* easy.
>
> These numbers were reproducable on all the platforms I tested.
It's not because they are reproducable
I've been following this thread closely as I have the same problem
with an UPDATE. Everything is identical here right down to the
strace output.
Has anyone found a workaround or resolved the problem? If not,
I have test systems here which I can use to help up test and explore.
Greg
--
Greg Spieg
20 matches
Mail list logo
