From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Typmod associated with multi-row VALUES constructs |
Date: | 2016-12-06 05:46:13 |
Message-ID: | CAKFQuwZ7RbLMbB4bzCY9JsGLWJJrFCGqY+91HMcjtj3cEugz0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 5, 2016 at 9:54 PM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> The concern is that "scan every row" could be very expensive - though in
> writing this I'm thinking that you'd quickly find a non-match even in a
> large dataset - and so a less perfect but still valid solution is to simply
> discard the typemod if there is more than one row.
>
My folly here - and the actual question to ask - is if you are faced with
large dataset that does have consistent typmods - is the benefit of knowing
what it is and carrying it to the next layer worth the cost of scanning
every single row to prove it is consistent?
My vote would be no - and the only question to ask is whether n = 1 and n >
1 behaviors should differ - to which I'd say no as well - at least in
master. In the back branches the current behavior would be retained if the
n = 1 behavior is kept different than the n > 1 behavior which is a worthy
trade-off.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-12-06 06:28:35 | Re: PSQL commands: \quit_if, \quit_unless |
Previous Message | Joseph Brenner | 2016-12-06 05:28:11 | Re: Select works only when connected from login postgres |