| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, ohp(at)pyrenet(dot)fr, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Index creation takes for ever |
| Date: | 2003-12-01 18:32:10 |
| Message-ID: | 24174.1070303530@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> comparetup_index() compares two IndexTuples. The structure
> IndexTupleData consists basically of not much more than an ItemPointer,
> and the patch is not much more than adding a comparison of two
> ItemPointers. So how does the patch introduce a new low level
> implementation dependency?
Because it sorts on tuple position, which is certainly about as low
level as you can get. More to the point, though, no evidence has been
provided that this is a good idea.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2003-12-01 18:59:50 | Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions? |
| Previous Message | Manfred Koizar | 2003-12-01 18:17:10 | Re: [HACKERS] Index creation takes for ever |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2003-12-01 18:32:13 | Re: export FUNC_MAX_ARGS as a read-only GUC variable |
| Previous Message | Manfred Koizar | 2003-12-01 18:17:10 | Re: [HACKERS] Index creation takes for ever |