(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
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 = 100)
] 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 PROTECTED] 07/18/05 2:24 PM
Hi
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
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 =
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
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
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]
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,
(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
10 matches
Mail list logo
