Re: qsort again (was Re: [PERFORM] Strange Create

From: "Gregory Maxwell" <gmaxwell(at)gmail(dot)com>
To: Ragnar <gnari(at)hive(dot)is>
Cc: Ron <rjpeace(at)earthlink(dot)net>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: qsort again (was Re: [PERFORM] Strange Create
Date: 2006-02-17 22:36:10
Message-ID: e692861c0602171436y3f627d32y1df152732da6936c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On 2/17/06, Ragnar <gnari(at)hive(dot)is> wrote:
> Say again ?
> Let us say you have 1 billion rows, where the
> column in question contains strings like
> baaaaaaaaaaaaaaa....aaa
> baaaaaaaaaaaaaaa....aab
> baaaaaaaaaaaaaaa....aac
> ...
> not necessarily in this order on disc of course
>
> The minimum value would be keyed as 00000001h,
> the next one as 00000002h and so on.
>
> Now insert new value 'aaaaa'
>
> Not only will you have to update 1 billion records,
> but also all the values in your map.
>
> please explain

No comment on the usefulness of the idea overall.. but the solution
would be to insert with the colliding value of the existing one lesser
than it..

It will falsly claim equal, which you then must fix with a second
local sort which should be fast because you only need to sort the
duplicates/false dupes. If you insert too much then this obviously
becomes completely useless.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-02-18 00:18:30 Re: Updated email signature
Previous Message Tom Lane 2006-02-17 20:01:51 Re: who is pgsql in cvs

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-02-18 05:53:04 Re: Index Choice Problem
Previous Message Lane Van Ingen 2006-02-17 20:26:19 Measuring Lock Performance