Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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. > >

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

Re: [HACKERS] Arrays of domains

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

[HACKERS] Arrays of domains

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