On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > I think this is a pretty neat idea, but I'm not sure this user interface > is a good one. Why not have a new option for EXPLAIN, so you would call > "EXPLAIN (planner_stuff=on)" and it returns this as a resultset?
Thank you for the feedback. Yeah, I agree piggy back on EXPLAIN sounds a better interface. A good thing about GUC is that it is global, so deep in planner we can see it. For example, in add_path(), where we add tracking of discarded paths. If we do EXPLAIN, we may either have to borrow another global variable, or add a flag on several planner data structures to make sure the flag can penetrate deep. Another thing is that with a GUC, we can mark it internal (PGC_INTERNAL), which compatibility maintenance might be relaxed, especially for this advanced option. > This idea of creating random CSV files seems odd and inconvenient in the > long run. For instance it fails if you have two sessions doing it > simultaneously; you could tack the process ID at the end of the file > name to prevent that problem, but then the foreign table breaks each > time. The reason to use CSV file is a kinda of balance. We do have other options, like pass data to pgstat, or persist in some shared memory/heap, but they all have their own issues. Any suggestion here? The file name is not random, it is fixed so we can create foreign table once and use it afterwards - I actually want to push them into system_views.sql. The file is opened with O_APPEND, the same way as log files, so concurrent writes are serialized. Read could be problematic though as no atomic guarantee between read/write. This is however a general issue of file_fdw, as the file is out of control of the core. We shall expect query returning format errors with concurrent read/write, and retry shall resolve the issue. Thanks, Qingqing -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
