| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: contrib/rtree_gist into core system? |
| Date: | 2005-06-28 19:21:24 |
| Message-ID: | 873br21e4r.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> 1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
> first keys on page are unique the the later keys will not be compared ;)
I'm confused now. I was under the impression that gist didn't look at
subsequent columns if the first column was identical.
Maybe I got it backwards and it's insert that fails to look at subsequent
columns but page split handles it ok? So if you insert lots of tuples with
identical first columns the page will be split intelligently but then
subsequent inserts will be distributed essentially randomly between the two
resulting pages.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2005-06-28 19:27:53 | Re: Proposed TODO: --encoding option for pg_dump |
| Previous Message | Josh Berkus | 2005-06-28 19:10:22 | Proposed TODO: --encoding option for pg_dump |