Re: [PERFORM] Is There Any Way ....

I'm sure there will be cases when some human assisted caching algorithm will perform better than an mathetical statistical based design, but it will also depend on the "human". And it probably will make thing worse when workload changes and human doesn't realize. It must be considered that, today,

Re: [PERFORM] Comparative performance

Postgresql uses MVCC to ensure data integrity. Server must choose the right version of tuple, according to transaction ID of statement. Even for a select (ACID features of postgresql, I think C and I apply here), it must accomplish some extra work. -Mensaje original- De: [EMAIL PROTECTED]

Re: [PERFORM] Is There Any Way ....

1) AFAIK, no. Just in case you are thinking "There should be a way coz I know it will be used all the time", you must know that postgresql philosophy is "I'm smarter than you". If table is used all the time, it will be in memory, if not, it won't waste memory. 2) don't know. 3) see number 1) Of cou

Re: [PERFORM] How to Trigger An Automtic Vacuum on Selected Tables

Autovacuum does exactly what I understood you want :-) -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Lane Van Ingen Enviado el: jueves, 29 de septiembre de 2005 20:06 Para: pgsql-performance@postgresql.org Asunto: [PERFORM] How to Trigger An Automtic Vacuum o

Re: [PERFORM] VACUUM FULL vs CLUSTER

you can see that at the end of vacuum log (sorry for my english) ... INFO: free space map: 930 relations, 48827 pages stored; 60240 total pages needed -- NEEDED! -- I have already configured in postgresql.conf, you can see it below DETAIL: Allocated FSM size: 1000 relations + 7 pages = 475

Re: [PERFORM] slow database, queries accumulating

I have read that 600 connections are a LOT (somebody correct me please if I'm wrong), since each connections requires a process and your server must serve this. Besides the overhead involved, you will end up with 1200 megabytes of sort_mem allocated (probably idle most of time)... pgpool allows yo

Re: [PERFORM] Left joining against two empty tables makes a query

Sorry for my english. May I ask? (i'm still learning postgresql). Isn't outer join forcing "join order"? The planner will resolve a, then ac in order to resolve left join previously and will not be able to choose the customer_id filter (more selective)... AFAIK (not too far :-)) this will be the jo

Re: [PERFORM] join and query planner

RFORM] join and query planner You might want to set join_collapse_limit high, and use the JOIN operators rather than the comma-separated lists. We generate the WHERE clause on the fly, based on user input, and this has worked well for us. -Kevin >>> "Dario" <[EMAIL P

Re: [PERFORM] join and query planner

Hi. > Just out of curiosity, does it do any better with the following? > >SELECT ... Yes, it does. But my query could also be SELECT ... FROM a JOIN b ON (a.key = b.key) LEFT JOIN c ON (c.key = a.key) LEFT JOIN d ON (d.key=a.key) /*new*/ , e WHERE (b.column <= 10

[PERFORM] join and query planner

(first at all, sorry for my english) Hi. - Does "left join" restrict the order in which the planner must join tables? I've read about join, but i'm not sure about left join... - If so: Can I avoid this behavior? I mean, make the planner resolve the query, using statistics (uniqueness, data di

[PERFORM] join and query planner

(first at all, sorry for my english) Hi. - Does "left join" restrict the order in which the planner must join tables? I've read about join, but i'm not sure about left join... - If so: Can I avoid this behavior? I mean, make the planner resolve the query, using statistics (uniqueness, data d

[PERFORM] ALTER TABLE tabla ALTER COLUMN columna SET STATISTICS number

¿where is stored the value set by ALTER TABLE table_name ALTER COLUMN column_name SET STATISTICS = [1-1000]? I've set this to 1000, and I didn't remember in which column (doh!). Is there any table to look? (I did 'grep "set stat" $PGDATA/pg_log/*' and found it, but may be there is a better way) I