From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: varlena beyond 1GB and matrix |
Date: | 2016-12-08 06:53:36 |
Message-ID: | CAMsr+YEPi6e6jXyo0y_E06T+RvJNij20Lxr3wyaT7dDEYrtv6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 December 2016 at 07:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Likewise, the need for clients to be able to transfer data in chunks
> gets pressing well before you get to 1GB. So there's a lot here that
> really should be worked on before we try to surmount that barrier.
Yeah. I tend to agree with Tom here. Allowing >1GB varlena-like
objects, when we can barely cope with our existing ones in
dump/restore, in clients, etc, doesn't strike me as quite the right
direction to go in.
I understand it solves a specific, niche case you're dealing with when
exchanging big blobs of data with a GPGPU. But since the client
doesn't actually see that large blob, it's split up into objects that
will work on the current protocol and interfaces, why is is necessary
to have instances of a single data type with >1GB values, rather than
take a TOAST-like / pg_largeobject-like approach and split it up for
storage?
I'm concerned that this adds a special case format that will create
maintenance burden and pain down the track, and it won't help with
pain points users face like errors dumping/restoring rows with big
varlena objects, problems efficiently exchanging them on the wire
protocol, etc.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-12-08 07:11:12 | Re: varlena beyond 1GB and matrix |
Previous Message | Kyotaro HORIGUCHI | 2016-12-08 06:04:36 | Re: Typmod associated with multi-row VALUES constructs |