On 12/02/2014 08:21 PM, Andres Freund wrote:
[snip]
2. Instead of the single amdata field, make it possible for the
implementation to define any number of fields with any datatype in the
tuple. That would make debugging, monitoring etc. easier.
My main problem with that approach is that it pretty much nails the door
shut for moving sequences into a catalog table instead of the current,
pretty insane, approach of a physical file per sequence.
Hmm... having done my fair bit of testing, I can say that this isn't
actually that bad (though depends heavily on the underlying filesystem
and workload, of course)
With this approach, I fear extreme I/O contention with an update-heavy
workload... unless all sequence activity is finally WAL-logged and hence
writes to the actual files become mostly sequential and asynchronous.
May I possibly suggest a file-per-schema model instead? This approach
would certainly solve the excessive i-node consumption problem that --I
guess-- Andres is trying to address here.
Moreover, the "one file per schema for sequences" solution would fit a
quite common model of grouping tables (in schemas) for physical
[tablespace] location purposes....
Currently, with
our without seqam, it'd not be all that hard to force it into a catalog,
taking care to to force each tuple onto a separate page...
IMHO, this is jst as wasteful as the current approach (one-page file per
sequence) in terms of disk usage and complicates the code a bit .... but
I really don't see how we can have more than one sequence state per page
without severe (page) locking problems.
However, someone with deeper knowledge of page pinning and buffer
manager internals could certainly devise a better solution...
Just my 2c
Thanks,
/ J.L.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
