From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Lang <dlang(at)invendra(dot)net> |
Cc: | Ron <rjpeace(at)earthlink(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [GENERAL] Creation of tsearch2 index is very |
Date: | 2006-01-21 20:55:49 |
Message-ID: | 1749.1137876949@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
David Lang <dlang(at)invendra(dot)net> writes:
> On Sat, 21 Jan 2006, Tom Lane wrote:
>> Ron <rjpeace(at)earthlink(dot)net> writes:
>>> Maybe we are over thinking this. What happens if we do the obvious
>>> and just make a new page and move the "last" n/2 items on the full
>>> page to the new page?
>>
>> Search performance will go to hell in a handbasket :-(. We have to make
>> at least some effort to split the page in a way that will allow searches
>> to visit only one of the two child pages rather than both.
> does the order of the items within a given page matter?
AFAIK the items within a GIST index page are just stored in insertion
order (which is exactly why Ron's suggestion above doesn't work well).
There's no semantic significance to it. It's only when we have to split
the page that we need to classify the items more finely.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tony Caduto | 2006-01-22 05:07:22 | Re: PostgreSQL Top 10 Wishlist |
Previous Message | Martijn van Oosterhout | 2006-01-21 20:35:58 | Re: [GENERAL] Creation of tsearch2 index is very slow |
From | Date | Subject | |
---|---|---|---|
Next Message | Rikard Pavelic | 2006-01-21 21:06:13 | Re: [PERFORMANCE] Stored Procedures |
Previous Message | Ümit Öztosun | 2006-01-21 20:55:23 | Slow queries consisting inner selects and order bys & hack to speed up |