På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian <br...@momjian.us <mailto:br...@momjian.us>>: On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > I would assume that having pg_largeobject in a separate tablespace is more and > more common these days, having real-cheap SAN vs. fast-SSD for normal tables/ > indexes/wal.
So common that no one has ever asked for this feature before? Sometimes one gets the feeling that one is the only one in the universe doing something one considers "quite common":-) > So - I'm wondering if we can fund development of pg_upgrade to cope with this > configuration or somehow motivate to getting this issue fixed? > > Would any of the PG-companies (2ndQ, EDB, PgPro) take a stab at this? > > Any feedback welcome, thanks. You would need to get buy-in that that community wants the relocation of pg_largeobject to be supported via an SQL command, and at that point pg_upgrade would be modified to support that. It is unlikely pg_upgrade is going to be modified to support something that isn't supported at the SQL level. Of course, you can create a custom version of pg_upgrade to do that. Doesn't "ALTER TABLE pg_largeobject SET TABLESPACE myspace_lo" count as being "at the SQL-level"? The whole problem seems to come from the fact that BLOBs are stored in pg_largeobject which for some reason is implemented as a system-catalogue in PG, which imposes all kinds of weird problems, from a DBA-perspective. Can we pay you at EDB for making such a custom version of pg_upgrade for 9.6? Thanks. -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>
