Message-ID: <7ae24b59-782a-a531-fae5-e498e4eaa0e7@enterprisedb.com>
Date: Mon, 23 Jan 2023 00:21:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: pg_stats and range statistics
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Egor Rogov <e.rogov@postgrespro.ru>,
 Soumyadeep Chakraborty <soumyadeep2007@gmail.com>,
 pgsql-hackers@lists.postgresql.org
References: <b67d8b57-9357-7e82-a2e7-f6ce6eaeec67@postgrespro.ru>
 <55c8ecd4-57d0-5c63-6fe3-1b81e8caea9d@enterprisedb.com>
 <CAE-ML+_69xE=hhw6ZU-BT5h9mR8u8p9BGrikToKPTGthK_VmZw@mail.gmail.com>
 <c178ed2d-d06a-a178-ff9e-f30547ff0e03@postgrespro.ru>
 <b4c7d719-41c3-4883-463a-6cd4a407b5ee@enterprisedb.com>
 <daff262b-84e9-575e-342f-b91e6fcba430@postgrespro.ru>
 <cca33c94-f3ea-3200-9195-ac923485d498@enterprisedb.com>
 <d30615c2-970e-7397-50e9-f08c540cda18@postgrespro.ru>
 <d6280c94-febf-c17d-f18b-773260089ebf@enterprisedb.com>
 <20230122213310.GQ13860@telsasoft.com>
Content-Language: en-US
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <20230122213310.GQ13860@telsasoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/7ae24b59-782a-a531-fae5-e498e4eaa0e7%40enterprisedb.com>
Precedence: bulk


On 1/22/23 22:33, Justin Pryzby wrote:
> On Sun, Jan 22, 2023 at 07:19:41PM +0100, Tomas Vondra wrote:
>> On 1/21/23 19:53, Egor Rogov wrote:
>>> Hi Tomas,
>>> On 21.01.2023 00:50, Tomas Vondra wrote:
>>>> This simply adds two functions, accepting/producing anyarray - one for
>>>> lower bounds, one for upper bounds. I don't think it can be done with a
>>>> plain subquery (or at least I don't know how).
>>>
>>> Anyarray is an alien to SQL, so functions are well justified here. What
>>> makes me a bit uneasy is two almost identical functions. Should we
>>> consider other options like a function with an additional parameter or a
>>> function returning an array of bounds arrays (which is somewhat
>>> wasteful, but probably it doesn't matter much here)?
>>>
>>
>> I thought about that, but I think the alternatives (e.g. a single
>> function with a parameter determining which boundary to return). But I
>> don't think it's better.
> 
> What about a common function, maybe called like:
> 
> ranges_upper_bounds(PG_FUNCTION_ARGS)
> {
>     AnyArrayType *array = PG_GETARG_ANY_ARRAY_P(0);
>     Oid         element_type = AARR_ELEMTYPE(array);
>     TypeCacheEntry *typentry;
> 
>     /* Get information about range type; note column might be a domain */
>     typentry = range_get_typcache(fcinfo, getBaseType(element_type));
> 
>     return ranges_bounds_common(typentry, array, false);
> }
> 
> That saves 40 LOC.
> 

Thanks, that's better. But I'm still not sure it's a good idea to add
function with anyarray argument, when we need it to be an array of
ranges ...

I wonder if we have other functions doing something similar, i.e.
accepting a polymorphic type and then imposing additional restrictions
on it.

> Shouldn't this add some sql tests ?
> 

Yeah, I guess we should have a couple tests calling these functions on
different range arrays.

This reminds me lower()/upper() have some extra rules about handling
empty ranges / infinite boundaries etc. These functions should behave
consistently (as if we called lower() in a loop) and I'm pretty sure
that's not the current state.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company