--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
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
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]
To:
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
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
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 =
