Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)
Date: Wed, 02 Jun 2004 17:44:18 +1000
Message-ID: <opr8yif4q9h454zx_at_news.optusnet.com.au>
On Tue, 01 Jun 2004 23:06:10 +0200, Hugo Kornelis
<hugo_at_pe_NO_rFact.in_SPAM_fo> wrote:
> On Tue, 01 Jun 2004 16:33:34 +1000, thirdrock wrote:
This maybe correct, or tempdb may be used as a swap space (like virtual
memory), so the temp table may not ever go into the cache if it is small
enough. Without knowing exactly how it is implemented it is hard to say.
As for logging changes to temp tables, are you sure about that? Not sure
what the point of that would be ... still I'm not saying it doesn't
>
>> On Sun, 30 May 2004 00:24:48 +0200, Hugo Kornelis
>> <hugo_at_pe_NO_rFact.in_SPAM_fo> wrote:
>>
>>> On 29 May 2004 11:18:22 -0700, Neo wrote:
>>
>>> No, they are not. There is no such thing as a "RAM table" in MS SQL
>>> Server.
>>
>> Yes there is. It's called a temporary table. Really fast too, but does
>> not
>> get flushed to disk at any point.
>
> Hi Ian,
>
>
> If the temp table is small enough to fit in memory and it is dropped soon
> after being created, then the data may be gone from the cache before
> being
> flushed to disk; the log records will still be written to disk (logging
> for temp tables is reduced, not completely avoided).
>> This was versionb
>> 6.5 so things may have improved since then.
>> Every other database I tested the same update on beat this performance
>> by
>> at least 50%, Oracle was 100% faster. Even Access was faster, but once
>> the
>> record count went above a million, Access started crashing and
>> corrupting
>> data.
>
> Not sure about the differences between 6.5 and 2000 myself either. Too
> bad
> I don't have Oracle at hand - from what you write I gather that I might
> have beaten Neo's challenge even more using Oracle!
:) ... or MySQL, which is really fast for selects.
have fun,
Ian
Received on Wed Jun 02 2004 - 09:44:18 CEST