Re: [PATCH] Opclass parameters

From: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>, Oleg Bartunov <obartunov(at)gmail(dot)com>
Subject: Re: [PATCH] Opclass parameters
Date: 2019-09-10 22:44:28
Message-ID: 0807f67b-c1bd-3760-7fc5-89900ae65408@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.09.2019 1:03, Tomas Vondra wrote:

> On Tue, Sep 10, 2019 at 04:30:41AM +0300, Nikita Glukhov wrote:
>
>> 2. New AM method amattoptions().
>>
>>   amattoptions() is used to specify per-column AM-specific options.
>>   The example is signature length for bloom indexes (patch #3).
>>
>
> I'm somewhat confused how am I supposed to use this, considering the
> patch
> set only defines this for the contrib/bloom index AM. So let's say I want
> to create a custom BRIN opclass with per-attribute options (like the two
> BRIN opclasses I work on in the other thread). Clearly, I can't tweak the
> IndexAmRoutine from the extension. ISTM the patch series should modify
> all
> existing index AMs to have a valid amattoptions() implementation, calling
> the new amproc if defined.
>
> Or what is the correct way to define custom opclass for existing index AM
> (e.g. BRIN) with attribute options?
>
Per-attribute opclass options are implemented independently from per-attribute
AM options. amattoptions() is optional and needs to be defined only if AM has
per-attribute options. amproc #0 is called regardless of whether amattoptions
is defined or not. That was the main reason why uniform procnum 0 was picked.

You should simply define function like that and use it as amproc #0:

Datum
brin_bloom_options(PG_FUNCTION_ARGS)
{
local_relopts *relopts = (local_relopts *) PG_GETARG_POINTER(0);
BloomOptions *blopts = NULL;

extend_local_reloptions(relopts, blopts, sizeof(*blopts));

add_local_real_reloption(relopts, "n_distinct_per_range", "desc",
-0.1, -1.0, INT_MAX, &blopts->nDistinctPerRange);

add_local_real_reloption(relopts, "false_positive_rate", "desc",
0.01, 0.001, 1.0, &blopts->falsePositiveRate);

PG_RETURN_VOID();
}

--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2019-09-10 23:27:06 Re: Planning counters in pg_stat_statements (using pgss_store)
Previous Message Julien Rouhaud 2019-09-10 22:30:25 Re: Planning counters in pg_stat_statements (using pgss_store)