Re: hash index improving v3
От | Simon Riggs |
---|---|
Тема | Re: hash index improving v3 |
Дата | |
Msg-id | 1222175115.4445.344.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: hash index improving v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: hash index improving v3
|
Список | pgsql-patches |
On Tue, 2008-09-23 at 08:16 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > maintenance_work_mem is already used for 3 separate operations that bear > > little resemblance to each other. If it's appropriate for all of those > > then its appropriate for this usage also. > > No, it isn't. > > The fundamental point here is that this isn't a memory allocation > parameter; it's a switchover threshold between two different behaviors. That's a little confusing since sorts switch their behaviour also, but use (some form of) work_mem, which is *also* their max allocation. I see the difficulty in understanding the algorithm's behaviour now. So shared_buffers is the wrong parameter, but even if we had a parameter it would be very difficult to set it. Thinks: Why not just sort all of the time and skip the debate entirely? I thought the main use case was for larger indexes, since that's when the number of levels in the index is significantly less than btrees? Do we need to optimise creation time of smaller hash indexes at all? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-patches по дате отправления: