Re: Typmod associated with multi-row VALUES constructs

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.

In response to

Browse pgsql-hackers by date

  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