| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] Duplicate index check in btbuild |
| Date: | 2000-01-31 16:00:57 |
| Message-ID: | 9990.949334457@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> In addition I could find no other place to check
> index uniqueness in tuplesort.c .
> Seems we have to give up the uniqueness check in comparetup_
> index() and have to check it in _bt_buildadd().
Checking index uniqueness in tuplesort is pretty much of a hack,
although kind of cool since it doesn't take any extra comparisons
to do it there. But if we're doing the wrong thing then it has
to be removed.
I'm a little unclear on *why* it's wrong though. Don't we grab an
exclusive lock on a table while building an index for it? (If not,
shouldn't we be doing so?) I don't see how there can be tuples of
uncertain commit state that need to be included in the index.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ed Loehr | 2000-01-31 16:31:39 | Re: [HACKERS] float4 confused as int?? |
| Previous Message | Tom Lane | 2000-01-31 15:52:35 | Re: [HACKERS] float4 confused as int?? |