Re: [HACKERS] Surjective functional indexes

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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: 2018-01-06 22:59:42
Message-ID: 20180106225942.GT2416@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Konstantin Knizhnik (k(dot)knizhnik(at)postgrespro(dot)ru) wrote:
> On 15.12.2017 01:21, Michael Paquier wrote:
> >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.
>
> Ok, looks like everybody think that autotune based on statistic is bad idea.
> Attached please find patch without autotune.

This patch appears to apply with a reasonable amount of fuzz, builds,
and passes 'make check', at least, therefore I'm going to mark it
'Needs Review'.

I will note that the documentation doesn't currently build due to this:

/home/sfrost/git/pg/dev/cleanup/doc/src/sgml/ref/create_index.sgml:302: parser error : Opening and ending tag mismatch: literal line 302 and unparseable
<term><literal>recheck_on_update</></term>

but I don't think it makes sense for that to stand in the way of someone
doing a review of the base patch. Still, please do fix the
documentation build when you get a chance.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-01-06 23:09:48 Re: [HACKERS] Secondary index access optimizations
Previous Message Stephen Frost 2018-01-06 22:51:18 Re: [HACKERS] Cached plans and statement generalization