On 09/29/2017 01:10 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/28/2017 05:44 PM, Tom Lane wrote:
>>> Assuming that that's going to happen for v11, I'm inclined to leave the
>>> optimization problem until the dust settles around CaseTestExpr.
>>> Does anyone feel that this can't be com
Andrew Dunstan writes:
> On 09/28/2017 05:44 PM, Tom Lane wrote:
>> Assuming that that's going to happen for v11, I'm inclined to leave the
>> optimization problem until the dust settles around CaseTestExpr.
>> Does anyone feel that this can't be committed before that's addressed?
> I'm Ok with i
On 09/28/2017 05:44 PM, Tom Lane wrote:
>
> I get these query timings in a non-cassert build:
>
> HEADPatch
>
> Q15453.235 ms 5440.876 ms
> Q29340.670 ms 10191.194 ms
> Q319078.457 ms18967.279 ms
> Q448196.338 ms58547.531 ms
>
>
[ analysis elided]
Andrew Dunstan writes:
> On 09/28/2017 01:11 PM, Tom Lane wrote:
>>> I wonder if we need to do any benchmarking to assure ourselves that the
>>> changes to ArrayCoerceExpr don't have a significant performance impact?
>> That would likely be a good idea, though I'm not very sure what or
>> how to
On 09/28/2017 01:11 PM, Tom Lane wrote:
>
>> I wonder if we need to do any benchmarking to assure ourselves that the
>> changes to ArrayCoerceExpr don't have a significant performance impact?
> That would likely be a good idea, though I'm not very sure what or
> how to benchmark.
>
>
Andrew Dunstan writes:
> On 08/11/2017 01:17 PM, Tom Lane wrote:
>> Attached is a patch series that allows us to create arrays of domain
>> types.
> I've reviewed and tested the updated versions of these patches. The
> patches apply but there's an apparent typo in arrayfuncs.c -
> DatumGetAnyArra
On 08/11/2017 01:17 PM, Tom Lane wrote:
> I wrote:
>> Probably a better answer is to start supporting arrays over domain
>> types. That was left unimplemented in the original domains patch,
>> but AFAICS not for any better reason than lack of round tuits.
> Attached is a patch series that allows
I wrote:
> Here's a rebased-up-to-HEAD version of this patch set. The only
> actual change is removal of a no-longer-needed hunk in pl_exec.c.
I see the patch tester is complaining that this broke, due to commit
4bd199465. The fix is trivial (s/GETARG_ANY_ARRAY/GETARG_ANY_ARRAY_P/)
but for conve
I wrote:
> Attached is a patch series that allows us to create arrays of domain
> types.
Here's a rebased-up-to-HEAD version of this patch set. The only
actual change is removal of a no-longer-needed hunk in pl_exec.c.
regards, tom lane
diff --git a/src/backend/optimizer
I wrote:
> Probably a better answer is to start supporting arrays over domain
> types. That was left unimplemented in the original domains patch,
> but AFAICS not for any better reason than lack of round tuits.
Attached is a patch series that allows us to create arrays of domain
types. I haven't
On 07/11/2017 12:44 PM, Tom Lane wrote:
>
> Can anyone think of a reason not to pursue that?
>
>
I'm all for it.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pg
On Tue, Jul 11, 2017 at 12:44:33PM -0400, Tom Lane wrote:
> Over in
> https://www.postgresql.org/message-id/877ezgyn60@metapensiero.it
> there's a gripe about array_agg() not working for a domain type.
> It fails because we don't create an array type over a domain type,
> so the parser can't id
Over in
https://www.postgresql.org/message-id/877ezgyn60@metapensiero.it
there's a gripe about array_agg() not working for a domain type.
It fails because we don't create an array type over a domain type,
so the parser can't identify a suitable output type for the polymorphic
aggregate.
We cou
13 matches
Mail list logo