Re: [PERFORM] Performance problem with table containing a lot of text (blog)

On Wed, 29 Aug 2007, Heikki Linnakangas wrote: The idea of being able to set the toast threshold per column was discussed during 8.3 development, but no patch was produced IIRC. We might do that in the future. If you're willing to compile from source, you can lower TOAST_TUPLE_THRESHOLD. We ar

Re: [PERFORM] Performance problem with table containing a lot of text (blog)

ith minimal I/O overhead. Yes. I was suggesting this as an option but I'm wondering if there are other solutions. |\__/| ( oo )Kari Lavikka - [EMAIL PROTECTED] - (050) 380 3808 __ooO( )Ooo___ _ ___ _ _ _ __ _ _ "" On Tue,

[PERFORM] Performance problem with table containing a lot of text (blog)

-> Index Scan using user_bookmark_pkey on user_bookmark fub (cost=0.00..3.42 rows=1 width=0) Index Cond: ((bookmark_group_id = $0) AND (marked_uid = 256979)) P.S. That particular user has quite many unread entries though... |\__/| ( oo )Ka

Re: [PERFORM] Finding bottleneck

art_collector = true stats_command_string = true |\__/| ( oo )Kari Lavikka - [EMAIL PROTECTED] - (050) 380 3808 __ooO( )Ooo___ _ ___ _ _ _ __ _ _ "" ---(end of broadcast)--- TIP 9:

Re: [PERFORM] Finding bottleneck

Some sort of connection pooling seems like a good idea, if you don't have it in place already. pg_pool for example? I'm planning to give it a try. regards, tom lane |\__/| ( oo )Kari Lavikka -

Re: [PERFORM] Finding bottleneck

ueries tend to take several minutes to execute although there's plenty of free cpu available. There aren't any blocking locks in pg_locks. |\__/| ( oo )Kari Lavikka - [EMAIL PROTECTED] - (050) 380 3808 __ooO( )Ooo___ _ ___ _ _ _ __ _

Re: [PERFORM] Finding bottleneck

number of concurrent queries increases, lseek and read syscalls stay within quite constant limits but number of semop calls quadruples. Are there some buffer locking issues? |\__/| ( oo )Kari Lavikka - [EMAIL PROTECTED] - (050) 380 3808 __ooO( )

[PERFORM] Finding bottleneck

default_statistics_target = 150 # range 1-1000 stats_start_collector = true stats_command_string = true |\__/| ( oo )Kari Lavikka - [EMAIL PROTECTED] - (050) 380 3808 __ooO( )Ooo___ _ ___ _ _ _ __ _ _ "" ---

Re: [PERFORM] Unique index and estimated rows.

27;::bpchar)) Total runtime: 0.303 ms (10 rows) I think that creating an uppercase column for name and unique index for could be a workaround for this. Another problem is that function indexes don't seem to care about statistics target settings. |\__/| ( oo )Kari Lavikka - [EMAIL

[PERFORM] Unique index and estimated rows.

us = 'a'::bpchar) -> Index Scan using image_uid_status on image i (cost=0.00..144.83 rows=20 width=53) (actual time=0.026..0.080 rows=19 loops=1) Index Cond: (i.uid = "outer".uid) Filter: ((status = 'd'::bpchar) OR (status = 

[PERFORM] Cost of indexscan

003-05-01 | 7119 | ** 2003-06-01 | 8978 | ** 2003-07-01 | 7723 | ** 2003-08-01 | 36566 | 2003-09-01 | 15759 | * 2003-10-01 | 10610 | *** 2003-11-01 | 83113 | *** 2003-12-01 | 90927 | ****** 2004-01-01 | 124479 | **

[PERFORM] a lot of problems with pg 7.4

6 0 678 769 5 0 95 0 There's some other slowness with 7.4 as well. After running just fine for several hours pg starts to eat a LOT of cpu. Query plans are just like normally and pg_stat_activity shows nothing special. Disconnecting and reconnecting all clients seems to help (re