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
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 wait behind them. Every time
> the ANALYZE sleeps it wakes up
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.
Simon Riggs <[EMAIL PROTECTED]> writes:
>> I don't understand why this would be. I don't think there
>> are any lock issues, and I don't see any obvious I/O issues.
> The ANALYZE commands hold read locks on the tables you wish to write to.
Unless there were more commands that Ian didn't show us,
> 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 Inform
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 th
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
>- Sun V250 server
>- 2*1.3GHz Sparc IIIi CPU
>- 8GB RAM
>- 8*73GB SCSI drives
>- Solaris 10
>- Postgres 8
>4) We moved the pg_xlog files off /data/postgres (disks 2-7) and into
>/opt/pg_xlog (disks 0-1), but it seemed like performance decreased,
>so we moved them back again.
You have saturated SC
(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
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 i<20 ORDER BY x || t;
QUERY PLAN
-
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 i<20 ORDER BY x || t;
> Q
"jobapply" <[EMAIL PROTECTED]> writes:
> The 2 queries are almost same, but ORDER BY x||t is FASTER than ORDER BY x..
> How can that be possible?
Hmm, how long are the x values? Is it possible many of them are
TOASTed?
regards, tom lane
---(end of
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 i<20 ORD
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 i<20 ORDER BY x || t;
> Q
16 matches
Mail list logo
