> On 26 Jul 2024, at 10:10, Michał Kłeczek wrote:
>
>
>
>> On 26 Jul 2024, at 01:28, Matthias van de Meent
>> wrote:
>>
>> All in all, this still seems like a very (very) specific optimization,
>> of which I'm not sure that it is generalizable. However, array
>> introspection and filtering
> On 26 Jul 2024, at 01:28, Matthias van de Meent
> wrote:
>
> All in all, this still seems like a very (very) specific optimization,
> of which I'm not sure that it is generalizable. However, array
> introspection and filtering for SAOP equality checks feel like a
> relatively easy (?) push-d
On Fri, 22 Mar 2024, 01:29 Michał Kłeczek, wrote:
> On 21 Mar 2024, at 23:42, Matthias van de Meent
> wrote:
>> On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote:
>>> With this operator we can write our queries like:
>>>
>>> account_number ||= [list of account numbers] AND
>>> account_number =
Hi Tom,
Thanks for looking at it.
> On 24 Jul 2024, at 22:19, Tom Lane wrote:
>
> =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
>> I understand extensibility of GIST makes many operators opaque to the
>> planner and it is the “consistent” function that can perform optimisations
>> (or we can
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
> I understand extensibility of GIST makes many operators opaque to the planner
> and it is the “consistent” function that can perform optimisations (or we can
> come up with some additional mechanism during planning phase).
> Providing more informati
> On 22 Mar 2024, at 10:11, Michał Kłeczek wrote:
>
>>
>> On 22 Mar 2024, at 01:29, Michał Kłeczek wrote:
>>
>>
>>
>>> On 21 Mar 2024, at 23:42, Matthias van de Meent
>>> wrote:
>>>
>>>
>>> You seem to already be using your own operator class, so you may want
>>> to look into CREATE F
> On 22 Mar 2024, at 01:29, Michał Kłeczek wrote:
>
>
>
>> On 21 Mar 2024, at 23:42, Matthias van de Meent
>> wrote:
>>
>>> On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote:
>>>
>>> With this operator we can write our queries like:
>>>
>>> account_number ||= [list of account numbers]
> On 21 Mar 2024, at 23:42, Matthias van de Meent
> wrote:
>
> On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote:
>
>> With this operator we can write our queries like:
>>
>> account_number ||= [list of account numbers] AND
>> account_number = ANY ([list of account numbers]) — redundant f
On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote:
>
> Hi All,
>
> Since it looks like there is not much interest in the patch I will try to
> provide some background to explain why I think it is needed.
>
[...]
> What we really need is for Gist to support “= ANY (…)”.
> As Gist index is extensi
Hi All,
Since it looks like there is not much interest in the patch I will try to
provide some background to explain why I think it is needed.
We are in the process of migration from an old db platform to PostgreSQL.
Our database is around 10TB big and contains around 10 billion financial
trans
Wrong file in the previous message - sorry for the noise.Attached is a fixed patch.Thanks,Michal
0001-Pass-key-sk_attno-to-consistent-function.patch
Description: Binary data
On 18 Mar 2024, at 15:14, Michał Kłeczek wrote:I realised it might be enough to pass sk_attno to consistent function as tha
I realised it might be enough to pass sk_attno to consistent function as that should be enough to lookup metadata if needed.Attached is a draft patch that does this.—Michal
0001-Pass-key-sk_attno-to-consistent-function.patch
Description: Binary data
On 18 Mar 2024, at 14:31, Michał Kłeczek wrote:
12 matches
Mail list logo
