Re: [PERFORM] Abnormal performance difference between Postgres and MySQL

2009-02-24 Thread Robert Haas
>> Can you please elaborate a bit? > > I thought that A0.Prop would ignore the composite index created on the > columns subj and prop but this does not seem to be the case. Yeah, I think you're barking up the wrong tree here. I think Tom had the correct diagnosis - what do you get from "show work

Re: [PERFORM] Abnormal performance difference between Postgres and MySQL

2009-02-24 Thread Claus Guttesen
>> > Query: >> > >> > select A0.Subj, A2.Obj From jena_g1t1_stmt A0, jena_g1t1_stmt A1, >> > jena_g1t1_stmt A2 Where >> > A0.Prop='Uv::http://prismstandard.org/namespaces/1.2/basic/isPartOf' AND >> > >> > A0.Obj='Uv::http://www.utdallas.edu/~farhan.husain/IngentaConnect/issue1_1' >> > AND A0.GraphI

Re: [PERFORM] Abnormal performance difference between Postgres and MySQL

2009-02-24 Thread Farhan Husain
On Tue, Feb 24, 2009 at 1:28 AM, Claus Guttesen wrote: > > I am doing a performance comparison between running Jena with MySQL and > > Postgres. I used the 8.3-community version of Postgres and MySQL 5.0.67. > I > > have run several queries to both MySQL and Postgres and all of them took > > simi

Re: [PERFORM] Abnormal performance difference between Postgres and MySQL

2009-02-24 Thread Farhan Husain
The result set should have 31 rows, that is correct. On Mon, Feb 23, 2009 at 7:53 PM, Scott Marlowe wrote: > On Mon, Feb 23, 2009 at 6:24 PM, Farhan Husain wrote: > This sort here: > > >-> Sort (cost=565372.46..568084.16 rows=1084680 width=74) (actual > > time=5410606.604..5410606.628 rows

Re: [PERFORM] LIMIT confuses the planner

2009-02-24 Thread Kouber Saparev
Tom Lane wrote: Kouber Saparev writes: Now the planner believes there're 910 rows, which is a bit closer to the real data: swing=# select avg(length) from (select username, count(*) as length from login_attempt group by username) as freq; avg -- 491.608731042

Re: [PERFORM] TCP network cost

2009-02-24 Thread Ross J. Reedstrom
Excellent. I'll take a look at this and report back here. Ross On Mon, Feb 23, 2009 at 04:17:00PM -0500, Tom Lane wrote: > "Ross J. Reedstrom" writes: > > Summary: C client and large-object API python both send bits in > > reasonable time, but I suspect there's still room for improvement in > >

[PERFORM] will 8.4 be able to optmize rank() windows ?

2009-02-24 Thread Grzegorz Jaśkiewicz
Question to core developers if I rank() a table, grouping by foo - but only will want to get first X result for every rank. Will postgresql be able to optimize that, or is it something left over for 8.5 in general? -- GJ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.

Re: [PERFORM] planner's midjudge number of rows resulting, despite pretty obvious join

2009-02-24 Thread Pavel Stehule
Hello 2009/2/24 Grzegorz Jaśkiewicz : > explain select ss, ARRAY(select id from foo where ss>0 and id between > 7 and 156 order by random() limit 3) as v from > generate_series(1,100) ss; >                                     QUERY PLAN > ---

[PERFORM] planner's midjudge number of rows resulting, despite pretty obvious join

2009-02-24 Thread Grzegorz Jaśkiewicz
explain select ss, ARRAY(select id from foo where ss>0 and id between 7 and 156 order by random() limit 3) as v from generate_series(1,100) ss; QUERY PLAN Function Scan on