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
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" <[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
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
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
-
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
(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
>- 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
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
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
> 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
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,
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 say
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
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
16 matches
Mail list logo
