| From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: CLUSTER and indisclustered |
| Date: | 2002-08-04 02:55:55 |
| Message-ID: | Pine.LNX.4.21.0208041250060.24736-100000@linuxworld.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 3 Aug 2002, Tom Lane wrote:
> Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > It occured to me on the plane home that now that CLUSTER is fixed we may
> > be able to put pg_index.indisclustered to use. If CLUSTER was to set
> > indisclustered to true when it clusters a heap according to the given
> > index, we could speed up sequantial scans.
>
> AFAICT you're assuming that the table is *exactly* ordered by the
> clustered attribute. While this is true at the instant CLUSTER
> completes, the exact ordering will be destroyed by the first insert or
> update :-(. I can't see much value in creating a whole new scan type
Sorry, I meant to say that heap_insert() etc would need to set
indisclustered to false.
I do see some worth in this however. Naturally, in a situation where a
database is being modified very often this is of little value. However,
for applications focussed on analysing large amounts of static data this
could increase performance significantly. Once I get some time I will
attempt to explore this further in `diff -c` format :-).
Gavin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-08-04 02:55:59 | Re: CLUSTER and indisclustered |
| Previous Message | Bruce Momjian | 2002-08-04 02:54:12 | Re: FUNC_MAX_ARGS benchmarks |