Re: [PERFORM] cost-based vacuum

2005-07-11 Thread Simon Riggs
On Fri, 2005-07-08 at 12:25 -0400, Ian Westmacott wrote: I am beginning to look at Postgres 8, and am particularly interested in cost-based vacuum/analyze. I'm hoping someone can shed some light on the behavior I am seeing. Suppose there are three threads: writer_thread every 1/15

[PERFORM] Question

2005-07-11 Thread Alejandro Lemus
In the past week, one guy of Unix Group in Colombia say: Postgrest in production is bat, if the power off in any time the datas is lost why this datas is in plain files. Postgrest no ssupport data bases with more 1 millon of records. Wath tell me in this respect?, is more best Informix as say

Re: [PERFORM] Question

2005-07-11 Thread Richard Huxton
Perhaps choose a better subject than question next time? Alejandro Lemus wrote: In the past week, one guy of Unix Group in Colombia say: Postgrest in production is bat, if the power off in any time the datas is lost Wrong. And it's called PostgreSQL. why this datas is in plain files.

Re: [PERFORM] Question

2005-07-11 Thread Magnus Hagander
In the past week, one guy of Unix Group in Colombia say: Postgrest in production is bat, if the power off in any time the datas is lost why this datas is in plain files. Postgrest no ssupport data bases with more 1 millon of records. Wath tell me in this respect?, is more best Informix as

Re: [PERFORM] cost-based vacuum

2005-07-11 Thread Simon Riggs
On Mon, 2005-07-11 at 09:07 -0400, Ian Westmacott wrote: On Mon, 2005-07-11 at 07:31, Simon Riggs wrote: The ANALYZE commands hold read locks on the tables you wish to write to. If you slow them down, you merely slow down your write transactions also, and then the read transactions that

Re: [PERFORM] Question

2005-07-11 Thread Gregory S. Williamson
As a sometimes Informix and PostgreSQL DBA, I disagree with the contentions below. We have many tables with 10s of millions of rows in Postgres. We have had (alas) power issues with our lab on more than one occasion and the afflicted servers have recovered like a champ, every time. This person

[PERFORM] join and query planner

2005-07-11 Thread Dario Pudlo
(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

Re: [PERFORM] join and query planner

2005-07-11 Thread John A Meinel
Dario Pudlo wrote: (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

[PERFORM] Sorting on longer key is faster ?

2005-07-11 Thread jobapply
The 2 queries are almost same, but ORDER BY x||t is FASTER than ORDER BY x.. How can that be possible? Btw: x and x||t are same ordered phoeniks= explain analyze SELECT * FROM test WHERE i20 ORDER BY x || t; QUERY PLAN

Re: [PERFORM] Sorting on longer key is faster ?

2005-07-11 Thread John A Meinel
Chris Travers wrote: John A Meinel wrote: jobapply wrote: The 2 queries are almost same, but ORDER BY x||t is FASTER than ORDER BY x.. How can that be possible? Btw: x and x||t are same ordered phoeniks= explain analyze SELECT * FROM test WHERE i20 ORDER BY x || t;

Re: [PERFORM] Sorting on longer key is faster ?

2005-07-11 Thread John A Meinel
jobapply wrote: The 2 queries are almost same, but ORDER BY x||t is FASTER than ORDER BY x.. How can that be possible? Btw: x and x||t are same ordered phoeniks= explain analyze SELECT * FROM test WHERE i20 ORDER BY x || t; QUERY PLAN