Message-ID: <c33ac4dd-daac-a478-2998-6742fa283451@enterprisedb.com>
Date: Thu, 23 Mar 2023 23:46:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: pg_stats and range statistics
Content-Language: en-US
To: Egor Rogov <e.rogov@postgrespro.ru>,
 "Gregory Stark (as CFM)" <stark.cfm@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
 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>
 <7ae24b59-782a-a531-fae5-e498e4eaa0e7@enterprisedb.com>
 <CAM-w4HPNsCOjYBLjHhRa0U54sTZ1h+P0Q7+3ruqWHYvMyGm0tg@mail.gmail.com>
 <ff213e30-ea79-90af-2d95-b53a5c377974@postgrespro.ru>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <ff213e30-ea79-90af-2d95-b53a5c377974@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/c33ac4dd-daac-a478-2998-6742fa283451%40enterprisedb.com>
Precedence: bulk


On 3/20/23 20:54, Egor Rogov wrote:
> On 20.03.2023 22:27, Gregory Stark (as CFM) wrote:
>> On Sun, 22 Jan 2023 at 18:22, Tomas Vondra
>> <tomas.vondra@enterprisedb.com> wrote:
>>> I wonder if we have other functions doing something similar, i.e.
>>> accepting a polymorphic type and then imposing additional restrictions
>>> on it.
>> Meh, there's things like array comparison functions that require both
>> arguments to be the same kind of arrays. And array_agg that requires
>> the elements to be the same type as the state array (ie, same type as
>> the first element). Not sure there are any taking just one specific
>> type though.
>>
>>>> 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.
>> Are we still waiting on these two items? Egor, do you think you'll
>> have a chance to work it for this month?
> 
> 
> I can try to tidy things up, but I'm not sure if we reached a consensus.
> 

We don't have any objections, and that's probably the best consensus we
can get here, I guess ...

So if you could clean it up a bit, and do something about the two open
items I mentioned (a bunch of tests on different array, and behavior
consistent with lower/upper), that'd be great.

> Do we stick with the ranges_upper(anyarray) and ranges_lower(anyarray)
> functions? This approach is okay with me. Tomas, have you made up your
> mind?
> 

I think the function approach is fine, but in my January 22 message I
was wondering why we're not actually naming them simply lower/upper.

> Do we want to document these functions? They are very
> pg_statistic-specific and won't be useful for end users imo.
> 

I don't see why not to document them. Sure, we're using them in a fairly
specific context, but I don't see why not to let people use them too
(which would be hard without docs).


regards

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