about lob(idea)

El 25/05/15 a las 06:13, alex2010 escribi�:

Maybe it makes sense to add ability to store large objects in the same table space as the table.
Or an opportunity - to specify table space for a large object.
Do you have anything in todolists about it?

This is something which has popped up on me more than once when giving
talks about storing files in PostgreSQL (last PgDay Argentina there was
quite a debate about it, particularly when bringing up the bytea <-> LO
comparison). The concerns the people exposed had different end goals.

One of the main concerns was the fact that all LO live in a common
catalog table (pg_largeobjects).

If the LO were stored per-database, with a some alike schema as
pg_largeobjects, then they could be placed on any tablespace available,
and even get dumped on a normal DB dump, which makes administration much
simpler.

Cheers,

--
Mart�n Marqu�s http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2015-05-27 0:01 GMT+02:00 Martín Marqués <martin@2ndquadrant.com>:

El 25/05/15 a las 06:13, alex2010 escribió:

Maybe it makes sense to add ability to store large objects in the same

table space as the table.

Or an opportunity - to specify table space for a large object.
Do you have anything in todolists about it?

This is something which has popped up on me more than once when giving
talks about storing files in PostgreSQL (last PgDay Argentina there was
quite a debate about it, particularly when bringing up the bytea <-> LO
comparison). The concerns the people exposed had different end goals.

One of the main concerns was the fact that all LO live in a common
catalog table (pg_largeobjects).

If the LO were stored per-database, with a some alike schema as
pg_largeobjects, then they could be placed on any tablespace available,
and even get dumped on a normal DB dump, which makes administration much
simpler.

I don't get it. They are already stored database per database. Each
database has its own pg_largeobjects catalog where all Large Objects for
this database are stored.

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On 5/27/15 5:02 AM, Guillaume Lelarge wrote:

2015-05-27 0:01 GMT+02:00 Martín Marqués <martin@2ndquadrant.com
<mailto:martin@2ndquadrant.com>>:

El 25/05/15 a las 06:13, alex2010 escribió:

Maybe it makes sense to add ability to store large objects in the same table space as the table.
Or an opportunity - to specify table space for a large object.
Do you have anything in todolists about it?

This is something which has popped up on me more than once when giving
talks about storing files in PostgreSQL (last PgDay Argentina there was
quite a debate about it, particularly when bringing up the bytea <-> LO
comparison). The concerns the people exposed had different end goals.

One of the main concerns was the fact that all LO live in a common
catalog table (pg_largeobjects).

If the LO were stored per-database, with a some alike schema as
pg_largeobjects, then they could be placed on any tablespace available,
and even get dumped on a normal DB dump, which makes administration much
simpler.

I don't get it. They are already stored database per database. Each
database has its own pg_largeobjects catalog where all Large Objects for
this database are stored.

There's also nothing preventing someone from creating a 'next
generation' LO PGXN extension that could be brought into core if enough
people show interest. That's probably the best route to get changes to
the existing LO infrastructure made.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers