Re: [HACKERS] Surjective functional indexes

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Surjective functional indexes
Date: 2017-12-14 22:21:00
Message-ID: CAB7nPqR8GPni-Y_Tr1+6XFdYCuum8a5MuB9q2+hnVcA7BYrorw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 15, 2017 at 6:15 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2017-12-14 22:41:24 worker_spi example BGW code GUC tweak
Previous Message Michael Paquier 2017-12-14 22:02:00 Re: incorrect error message, while dropping PROCEDURE