Re: [PATCH] Do not use StdRdOptions in Access Methods

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dent John <denty(at)qqdd(dot)eu>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods
Date: 2019-11-22 07:34:05
Message-ID: 20191122073405.GE42684@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 21, 2019 at 09:39:53PM +0300, Nikolay Shaplov wrote:
> BRIN_AM_OID and friends are defined in catalog/pg_am_d.h so for core indexes
> we can do relation->rd_rel->relam == BRIN_AM_OID check. But for contrib
> indexes we can't do such a thing.
> Bloom index does not need such check as it uses options only when index is
> created. At that point you can not choose wrong relation. But if in future we
> will have some contrib index that uses options when it some data is inserted
> (as it is done with fillfactor in core indexes) then index author will not be
> able to do such relam check. I would not call it a big problem, but it is
> something to think about, for sure...

I don't think that you actually need that for custom index AMs anyway,
as all code paths leading to the lookup of their reloption values is
within the module they are defined in.

> Thaks for joining this work, and sorry for late replies. Now I quite rarely
> have time for postgres :-(

We all have a life, don't worry. I am glad to see you around.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-11-22 07:44:50 Re: [PATCH] Do not use StdRdOptions in Access Methods
Previous Message Konstantin Knizhnik 2019-11-22 07:32:51 Re: Why overhead of SPI is so large?