Re: [PERFORM] sequence scan on PK

regards -- Matteo Beccati http://phpadsnew.com/ http://phppgads.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] sequence scan on PK

Hi, Yes , it was a bit to high (18) so a lowered it. It speeded up some pages for about 5%. 18? The default is 4 if I can remember correctly. I wonder if your db has ever seen an index scan ;) Best regards -- Matteo Beccati http://phpadsnew.com/ http://phppgads.com

[PERFORM] ltree <@ operator selectivity causes very slow plan

ion: SELECT COUNT(*) FROM gw_users; count --- 5012 SELECT COUNT(*) FROM gw_users WHERE tree <@ '1041'; count --- 4684 Is there anything I can do apart from disabling nested loops? Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

[PERFORM] ORDER BY and LIMIT not propagated on inherited tables / UNIONs

does)? I needed a quick solution, so I wrote a function which looks each inherited table separately and my problem is partially solved, but I think that a (hopefully) little change in the optimizer could be advisable. Attached are some EXPLAIN ANALYZE outputs of my suggestion. Best regards

Re: [PERFORM] ORDER BY and LIMIT not propagated on inherited

output. Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PERFORM] ORDER BY and LIMIT not propagated on inherited

r ones. Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] ORDER BY and LIMIT not propagated on inherited

would be harder to do in the general case, even if Matteo's simple transform looks good. I'm not sure it's a very common query type though... If I can find some time, I'll try to write some hacks... I just need to find out where to start ;) Best regards -- Matteo Becc

Re: [PERFORM] Deleting Records

g key? Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PERFORM] INSERTs becoming slower and slower

many queries. Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your

Re: [PERFORM] 500x speed-down: Wrong query plan?

e statistics for the id_ente column. P.S. There is also an italian mailing list, if you are interested :) Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planne

Re: [PERFORM] Wrong plan sequential scan instead of an index one

, but Tom could better advise. Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] 3ware vs. MegaRAID

took some effort as it involves having Linux emulation running but it's now working fine. I wouldn't dare to use it for write operations as I remember it freezing the box just after upgrading to amd64 (it was working good on i386). Cheers -- Matteo Beccati Development & Consulting

Re: [PERFORM] 3ware vs. MegaRAID

27 03:00:00 2010 + +Code: 0x0027 +Class: 0 +Locale: 0x20 +Event Description: Patrol Read started +Event Data: + None etc... Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] NOT LIKE much faster than LIKE?

patch which is currently on hold for the next release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold http://candle.pha.pa.us/mhonarc/patches_hold/msg00026.html The patch was addressing a similar issue when using ltree <@ and @> operator on an unbalanced tree. Best regards -

Re: [PERFORM] Inactive memory Grows unlimited

setup: shared_buffers = 1000 work_mem = 131076 You should really raise shared_buffers and decrease work_mem: 1000 shared_buffers is probably too conservative. On the other hand 128MB per sort could be eating your RAM quickly with 18 users connected. Best regards -- Matteo Beccati http://php

Re: [PERFORM]

sql function called at regular intervals, so this isn't a problem for me. I didn't test it, but I think some rules (or a trigger) could do the trick. Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Query performance over a large proportion of data

of the FreeBSD port for AMD/Intel 64 bit CPUs. See: http://www.freebsd.org/platforms/amd64.html and: http://en.wikipedia.org/wiki/X86-64 Cheers -- Matteo Beccati OpenX - http://www.openx.org -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to you

Re: [PERFORM] PostgreSQL 9.0.4 blocking in lseek?

hot_standby max_wal_senders = 2 wal_keep_segments = 256 Streaming replication was accidentally left enabled during the run, but I'm pretty sure that I didn't set it up yet when we had the previous failure. I'll be happy to provide more information. For now we're going to disconne

Re: [PERFORM] PostgreSQL 9.0.4 blocking in lseek?

6549500 lseek(10, 0, SEEK_END) = 27623424 ... I've then decided to interrupt the EXPLAIN ANALYZE. But I suppose that the database as it is now will likely allow to further debug what's happening. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- Sent

Re: [PERFORM] PostgreSQL 9.0.4 blocking in lseek?

lain.depesz.com/s/TqD The query eventually completed in more than 18h. For comparison a normal run doesn't take more than 1m for that specific step. Do you think that bad stats and suboptimal plan alone could explain such a behaviour? Cheers -- Matteo Beccati Development & Consulting - htt

Re: [PERFORM] PostgreSQL 9.0.4 blocking in lseek?

On 28/12/2011 19:07, Claudio Freire wrote: > On Wed, Dec 28, 2011 at 3:02 PM, Matteo Beccati wrote: >> The query eventually completed in more than 18h. For comparison a normal >> run doesn't take more than 1m for that specific step. >> >> Do you think that bad

Re: [PERFORM] PostgreSQL 9.0.4 blocking in lseek?

On 28/12/2011 19:41, Matteo Beccati wrote: > On 28/12/2011 19:07, Claudio Freire wrote: >> On Wed, Dec 28, 2011 at 3:02 PM, Matteo Beccati wrote: >>> The query eventually completed in more than 18h. For comparison a normal >>> run doesn't take more than 1m for th