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
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
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.
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
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
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
(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
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
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
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;
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
11 matches
Mail list logo