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
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 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 plac
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
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
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
"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
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
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
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
> > ar
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
[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
[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
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
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 6
20 matches
Mail list logo
