David Wall <d.wall@computer.org> writes:
>>> There are only 32 table, no functions, but mostly large objects. Not
>>> sure how to know about the LOs, but a quick check from the table sizes I
>>> estimate at only 2GB, so 16GB could be LOs. There are 7,528,803 entries
>>> in pg_catalog.pg_largeobject.
>> Hmm ... how many rows in pg_largeobject_metadata?
> pg_largeobject_metadata reports 1,656,417 rows.
> By the way, what is pg_largeobject_metadata vs. pg_largeobject since the
> counts are so different?
There's one row in pg_largeobject_metadata per large object. The rows in
pg_largeobject represent 2KB "pages" of large objects (so it looks like
your large objects are averaging only 8KB-10KB apiece). The "metadata"
table was added in 9.0 to carry ownership and access permission data for
each large object.
I think this report confirms something we'd worried about during 9.0
development, which was whether pg_dump wouldn't have issues with
sufficiently many large objects. At the time we'd taught it to handle LOs
as if they were full-fledged database objects, since that was the easiest
way to piggyback on its existing machinery for handling ownership and
permissions; but that's rather expensive for objects that don't really
need all the trappings of, eg, dependency tracking. We'd done some
measurements that seemed to indicate that the overhead wasn't awful for
medium-size numbers of large objects, but I'm not sure we tried it for
millions of 'em.
I guess the good news is that it's only being a bit slow for you and not
falling over completely. Still, it seems like some more work is indicated
in this area.
regards, tom lane
