Horton

Re: [HACKERS] Surjective functional indexes

Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

View thread View on postgr.es
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Michael Paquier <michael.paquier@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Simon Riggs <simon@2ndquadrant.com>, Christoph Berg <myon@debian.org>, Thomas Munro <thomas.munro@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-12-15T09:14:05Z
Lists: pgsql-hackers

Attachments


On 15.12.2017 01:21, Michael Paquier wrote:
> On Fri, Dec 15, 2017 at 6:15 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> Konstantin Knizhnik wrote:
>>> If you still thing that additional 16 bytes per relation in statistic is too
>>> high overhead, then I will also remove autotune.
>> I think it's pretty clear that these additional bytes are excessive.
> The bar to add new fields in PgStat_TableCounts in very high, and one
> attempt to tackle its scaling problems with many relations is here by
> Horiguchi-san:
> https://www.postgresql.org/message-id/20171211.201523.24172046.horiguchi.kyotaro@lab.ntt.co.jp
> His patch may be worth a look if you need more fields for your
> feature. So it seems to me that the patch as currently presented has
> close to zero chance to be committed as long as you keep your changes
> to pgstat.c.


Ok, looks like everybody think that autotune based on statistic is bad idea.
Attached please find patch without autotune.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Commits

  1. Finish reverting "recheck_on_update" patch.