> Almost any cross dbms migration shows a drop in performance. The engine
> effectively trains developers and administrators in what works and what
> doesn't. The initial migration thus compares a tuned to an untuned version.
I think it is also possible that Microsoft has more programmers working
On Sat, 2004-04-03 at 03:50, Gary Doades wrote:
> On 2 Apr 2004 at 22:36, [EMAIL PROTECTED] wrote:
>
> OK, some more detail:
>
> Before wiping 2.4 off my test box for the second time:
Perhaps I missed it, but which io scheduler are you using under 2.6?
---(end of bro
On Fri, 2 Apr 2004, Tom Lane wrote:
> Could we see EXPLAIN ANALYZE output?
The original EXPLAIN output was:
QUERY PLAN
--
Nested Loop (cost=0.00..196642756520.34 rows=49506496044
Almost any cross dbms migration shows a drop in performance. The engine
effectively trains developers and administrators in what works and what
doesn't. The initial migration thus compares a tuned to an untuned version.
/Aaron
- Original Message -
From: "Josh Berkus" <[EMAIL PROTECTED]>
Following on from Josh's response and my previous reply on SQLServer planning.
The main problem query is this one:
SELECT VS.*,VL.TEL1,SC.CONTRACT_ID,SC.CONTRACT_REF, SC.MAX_HOURS,
SC.MIN_HOURS,
(SELECT COUNT(*) FROM TIMESHEET_DETAIL JOIN MAIN_ORDER ON
(MAIN_ORDER.ORDER_ID = TIMESHEET_DETAIL.
Sorry, I think I misread your post in my last reply. I thought you were still talking
about
the big update
The main thing I have noticed about SQLServer is it seems more willing to do hash or
merge joins than PostgreSQL. I have experimented with various postgresql.conf
parameters and even
Thanks,
I know about set showplan_text, but it is only the equivalent of explain,
not explain analyze. The graphical plan gives full statistics, runtime,
percentage cost, loop execution counts etc. which is much more useful.
I don't know of a way of getting the graphical plan content in text fo
Actually it hasn't been my experience either. Most of my queries against
the database, large and small are either a little quicker or no real
difference. I have only really noticed big differences under stress when
memory (RAM) is being squeezed. The main winner on 2.6 seems to be
write perform
Gary,
> There are no indexes on the columns involved in the update, they are
> not required for my usual select statements. This is an attempt to
> slightly denormalise the design to get the performance up comparable
> to SQL Server 2000. We hope to move some of our databases over to
> Pos
--On fredag, april 02, 2004 09.56.04 -0600 Bruno Wolff III <[EMAIL PROTECTED]>
wrote:
On Fri, Apr 02, 2004 at 01:00:45 +0200,
Palle Girgensohn <[EMAIL PROTECTED]> wrote:
Is it always bad to create index xx on yy (field1, field2, field3);
I guess the problem is that the index might often grow b
On 2 Apr 2004 at 22:36, [EMAIL PROTECTED] wrote:
OK, some more detail:
Before wiping 2.4 off my test box for the second time:
SQL Statement for update:
update staff_booking set time_from = r.time_from from order_reqt r where r.reqt_id =
staff_booking.reqt_id;
Explain: (on 2.4)
QUERY PLAN
11 matches
Mail list logo
