Re: [PERFORM] Test

2010-11-03 Thread Robert Gravsjö
On 2010-11-02 22.21, Mladen Gogala wrote: Can you hear me now? sure -- Regards, Robert "roppert" Gravsjö -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] Test

2010-11-02 Thread Mladen Gogala
Can you hear me now? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscrip

Re: [PERFORM] test send (recommended by Dave Page)

2010-01-27 Thread Dave Page
On Wed, Jan 27, 2010 at 3:33 PM, Mark Steben wrote: > Hi all – sorry to create additional email ‘noise’ > > But I’ve been trying to post a rather long query to > > The pgsql-performance user list.  Dave thought > > That it might have been bounced due to the length > > And suggested I send a short

Re: [PERFORM] test send (recommended by Dave Page)

2010-01-27 Thread Matthew Wakeling
On Wed, 27 Jan 2010, Mark Steben wrote: Subject: [PERFORM] test send (recommended by Dave Page) Hi all - sorry to create additional email 'noise' But I've been trying to post a rather long query to The pgsql-performance user list. Dave thought That it might have been bou

[PERFORM] test send (recommended by Dave Page)

2010-01-27 Thread Mark Steben
Hi all - sorry to create additional email 'noise' But I've been trying to post a rather long query to The pgsql-performance user list. Dave thought That it might have been bounced due to the length And suggested I send a short 'blast' If this works I'll send a shortened version of my query

[PERFORM] test

2009-01-19 Thread Akos Gabriel
sorry, I just wonder why I can't get my message delivered... -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Tom Lane
Christo Du Preez <[EMAIL PROTECTED]> writes: > Fast: > "public";"layertype";"parentid";0.98797;4;2;"{4,1}";"{0.00902256,0.00300752}";"";-0.142857 > Slow: > "public";"layertype";"parentid";0.00745157;4;7;"{300}";"{0.976155}";"{1,1,4,5,8,12}";0.92262 Well, those statistics are almost completely dif

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Christo Du Preez
Fast: "public";"layertype";"id";0;4;-1;"";"";"{1,442,508,575,641,708,774,840,907,973,1040}";0.95 "public";"layertype";"label";0;14;-0.971429;"{arch,bank,bench,canyon,gap,hill,hills,levee,mountain,mountains}";"{0.00300752,0.00300752,0.00300752,0.00300752,0.00300752,0.00300752,0.00300752,0.00300

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Tom Lane
Christo Du Preez <[EMAIL PROTECTED]> writes: > Yes, I have just about tried every combination of vacuum on the > database. Just to make 100% sure. Well, there's something mighty wacko about that rowcount estimate; even if you didn't have stats, the estimate for a simple equality constraint oughtn'

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Christo Du Preez
Yes, I have just about tried every combination of vacuum on the database. Just to make 100% sure. Tom Lane wrote: > Christo Du Preez <[EMAIL PROTECTED]> writes: > >> On my laptop the explain analyze looks like this: >> > > >> "Index Scan using fki_layertype_parentid on layertype (cost=

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Tom Lane
Christo Du Preez <[EMAIL PROTECTED]> writes: > On my laptop the explain analyze looks like this: > "Index Scan using fki_layertype_parentid on layertype (cost=0.00..8.27 > rows=1 width=109)" > " Index Cond: (parentid = 300)" OK ... > and on the problem server: > "Seq Scan on layertype (cost=

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Steinar H. Gunderson
On Tue, Jun 12, 2007 at 04:11:33PM +0200, Christo Du Preez wrote: > The actual table I noticed the problem has a million rows and it still > doesn't use indexing Then please post an EXPLAIN ANALYZE of the query that is slow, along with the table definition and indexes. /* Steinar */ -- Homepage:

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Steinar H. Gunderson
On Tue, Jun 12, 2007 at 03:32:40PM +0200, Christo Du Preez wrote: > As an example I took a table with about 650 rows, having a parentid > field with an index on parentid. Try a bigger table. Using an index for only 650 rows is almost always suboptimal, so it's no wonder the planner doesn't use the

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Dave Dutcher
> From: Christo Du Preez > Sent: Tuesday, June 12, 2007 2:38 AM > > Where do I set the planner settings or are you reffering to > settings in postgres.conf that may affect the planner? > Yes I'm reffering to settings in postgres.conf. I'm wondering if enable_indexscan or something got turned o

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Alvaro Herrera
Christo Du Preez wrote: > The actual table I noticed the problem has a million rows and it still > doesn't use indexing So ANALYZE it. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "Amanece. (Ignacio Reyes) El Cerr

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Christo Du Preez
The actual table I noticed the problem has a million rows and it still doesn't use indexing Reid Thompson wrote: > try it with a table with 650K rows... > > On Tue, 2007-06-12 at 15:32 +0200, Christo Du Preez wrote: > >> Good day, >> >> I have noticed that my server never uses indexing. No matt

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Gregory Stark
"Christo Du Preez" <[EMAIL PROTECTED]> writes: > On my laptop the explain analyze looks like this: > > "Index Scan using fki_layertype_parentid on layertype (cost=0.00..8.27 > rows=1 width=109)" > " Index Cond: (parentid = 300)" That's not "explain analyze", that's just plain "explain". --

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Michael Glaesemann
On Jun 12, 2007, at 8:32 , Christo Du Preez wrote: I have noticed that my server never uses indexing. No matter what I do. As an example I took a table with about 650 rows, having a parentid field with an index on parentid. EXPLAIN ANALYZE SELECT * FROM layertype where parentid = 300; T

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Reid Thompson
try it with a table with 650K rows... On Tue, 2007-06-12 at 15:32 +0200, Christo Du Preez wrote: > Good day, > > I have noticed that my server never uses indexing. No matter what I do. > > As an example I took a table with about 650 rows, having a parentid > field with an index on parentid. > >

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Christo Du Preez
Good day, I have noticed that my server never uses indexing. No matter what I do. As an example I took a table with about 650 rows, having a parentid field with an index on parentid. EXPLAIN ANALYZE SELECT * FROM layertype where parentid = 300; On my laptop the explain analyze looks like this

Re: [PERFORM] test / live environment, major performance difference

2007-06-12 Thread Christo Du Preez
Where do I set the planner settings or are you reffering to settings in postgres.conf that may affect the planner? The one badly performing laptop is the same as mine (the fast one) and the server is much more powerful. Laptops: Intel Centrino Duo T2600 @ 2.16GHz, 1.98 GB RAM Server: 2 xIntel Pe

Re: [PERFORM] test / live environment, major performance difference

2007-06-11 Thread Christo Du Preez
I wonder if my dump/restore routine isn't causing this issue. Seeing that I do the db development on my laptop (the fast one) and then restores it on the other two machines. I have confirmed if all the indexes are present after a restore. This is the routine: /usr/local/pgsql/bin/pg_dump -t layer

Re: [PERFORM] test / live environment, major performance difference

2007-06-11 Thread Craig James
On 2007-06-11 Christo Du Preez wrote: I really hope someone can shed some light on my problem. I'm not sure if this is a posgres or potgis issue. Anyway, we have 2 development laptops and one live server, somehow I managed to get the same query to perform very well om my laptop, but on both the

Re: [PERFORM] test / live environment, major performance difference

2007-06-11 Thread Dave Dutcher
> -Original Message- > From: Christo Du Preez > Sent: Monday, June 11, 2007 10:10 AM > > I have narrowed down the problem (I think) and it's the query > planner using different plans and I haven't got a clue why. > Can anyone please shed some light on this? Different plans can be caused

Re: [PERFORM] test / live environment, major performance difference

2007-06-11 Thread Ansgar -59cobalt- Wiechers
On 2007-06-11 Christo Du Preez wrote: > I really hope someone can shed some light on my problem. I'm not sure > if this is a posgres or potgis issue. > > Anyway, we have 2 development laptops and one live server, somehow I > managed to get the same query to perform very well om my laptop, but > on

[PERFORM] test / live environment, major performance difference

2007-06-11 Thread Christo Du Preez
Hi All, I really hope someone can shed some light on my problem. I'm not sure if this is a posgres or potgis issue. Anyway, we have 2 development laptops and one live server, somehow I managed to get the same query to perform very well om my laptop, but on both the server and the other laptop it'

[PERFORM] test ...please ignore

2007-03-13 Thread Dengler, Michael
Test...please ignore Thanks Mike

[PERFORM] test - pls delete and ignore

2005-05-25 Thread Mohan, Ross
You just couldn't help yourself, could you? :-) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[PERFORM] test post

2004-10-05 Thread Max Baker
please ignore if this goes through. They've been bouncing and I'm trying to find out why. -m ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Test...

2003-09-29 Thread Tom Lane
David Griffiths <[EMAIL PROTECTED]> writes: > Is there a size limit to an email IIRC, the standard policy on the pgsql lists is that messages over 40K or so will be delayed for moderator approval. However, you should have gotten immediate replies from the majordomo 'bot telling you so. If you go

[PERFORM] Test...

2003-09-29 Thread David Griffiths
I've posted several emails, and have yet to see one show up (this one might not either).   Is there a size limit to an email (it had a big analyze, and schema information)?? David