From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Antonio Fiol Bonnín <fiol(at)w3ping(dot)com> |
Cc: | Nevermind <never(at)nevermind(dot)kiev(dot)ua>, PostgreSQL General Mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Database tuning |
Date: | 2001-12-22 02:28:22 |
Message-ID: | 21126.1008988102@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Antonio Fiol =?ISO-8859-1?Q?Bonn=EDn?= <fiol(at)w3ping(dot)com> writes:
> Better: "Compress" your table so that it holds all continuous IDs.
It's not really necessary to do that. Assuming that you know the
range of IDs, you could do
select ... where id >= (random() * MAX) order by id limit 1;
(where you actually need to do the random() calculation on the client
side so you can send a constant in the query; or else cheat using a
user-defined function that's marked "iscachable". Search for
"iscachable" in the mail list archives to see more about that fine
point.)
This should produce an indexscan plan that starts scanning at
(random() * MAX) and stops as soon as it's got the first tuple.
If you have wide gaps in the ID sequence then the items just after
each such gap will be disproportionately likely to be chosen by this
approach. So it's not perfect. But minor irregularity in the sequence
of IDs can be tolerated this way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-22 02:39:10 | Re: Stored procedures vs Functions |
Previous Message | Alvaro Herrera | 2001-12-22 02:15:58 | Re: Pl/Tcl problem |