Re: Temporary file access API - Mailing list pgsql-hackers

I’m a latecomer to the discussion, but as a word of introduction, I’m working with Stephen, and I have started looking over the temp file proposal with the idea of helping it move along.

I’ll start by summarizing the temp file proposal and its goals.

From a high level, the proposed code:

• Creates an fread/fwrite replacement (BufFileStream) for buffering data to a single file.
• Updates BufFile, which reads/writes a set of files, to use BufFileStream internally.
• Does not impact the normal (page cached) database I/O.
• Updates all the other places where fread/fwrite and read/write are used.
• Creates and removes transient files.

I see the following goals:

• Unify all the “other” file accesses into a single, consistent API.
• Integrate with VFDs.
• Integrate transient files with transactions and tablespaces.
• Create a consolidated framework where features like encryption and compression can be more easily added.
• Maintain good streaming performance.

Is this a fair description of the proposal?

For myself, I’d like to map out how features like compression and encryption would fit into the framework, more as a sanity check than anything else, and I’d like to look closer at some of the implementation details. But at the moment, I want to make sure I have the proper high-level view of the temp file proposal.