On Tue, May 17, 2016 at 1:53 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > What kind of special treatment are you expecting for temporary_files_size, > also why do you think it is required? Currently neither we build hash in > parallel nor there is any form of parallel sort work.
I expect only that temporary_files_size be described accurately, and have new behavior for parallel query that is not surprising. There are probably several solutions that would meet that standard, and I am not attached to any particular one of them. I wrote a parallel sort patch already (CREATE INDEX for the B-Tree AM), and will post it at an opportune time. So, I think we can expect your observations about there not being parallel sort work to no longer apply in a future release, which we should get ahead of now. Also, won't parallel workers that build their own copy of the hash table (for a hash join) also use their own temp files, if there is a need for temp files? I think parallel query will end up sharing temp files fairly often, and not just out of convenience to implementers (that is, not just to avoid using shared memory extensively). Fundamentally, since temporary_files_size enforcement simply piggy-backs on low-level fd.c file management, without any consideration of what the temp files contain, it'll be hard to be sure that parallel workers will not have issues. I think it'll be far easier to fix the problem then it would be to figure out if it's possible to get away with it. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
