Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Дата | |
Msg-id | CAM3SWZRPkuxiT0EmCLCd3xjA=AWbfuy1qv-89r4iMTOtYFZJ4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #14210: filter by "=" constraint doesn't work when
hash index is present on a column
|
Список | pgsql-bugs |
On Mon, Jun 27, 2016 at 1:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Geoghegan <pg@heroku.com> writes: >> I like this idea. Should I write a patch? > > BTW, while you're at it: it strikes me that the threshold should be > either min(NBuffers, maintenance_work_mem) or > min(NLocBuffer, maintenance_work_mem), depending on whether we're > talking about a regular or temp table/index. That is, there's a > pre-existing bug here that when NLocBuffer is a good deal less than > NBuffers (which is the typical case nowadays) you'll get a lot of > thrashing between local buffers and kernel cache, if the index isn't > quite big enough to trigger the sorting code. This might not manifest > as actual I/O, but it's not the intended behavior either. Understood. It's on my TODO list for the week, although I'll prioritize isolating and fixing that UPSERT "attempted to delete invisible tuple" bug. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: