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
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
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
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
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
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
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 included in the
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
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 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 the
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
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 that
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 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
are
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
[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
[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
I
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 vs
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
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 64
20 matches
Mail list logo
