Database Reference
In-Depth Information
There is another way of doing this, as well.
DO $$
DECLARE c record;
BEGIN
FOR c IN SELECT t.*, n.nspname
FROM pg_class c JOIN pg_namespace n
ON c.relnamespace = n.oid
WHERE n.nspname = 'test' /* ; not needed */
LOOP
EXECUTE 'ALTER TABLE '|| quote_ident(n.nspname) ||
'.' || quote_ident(c.relname) ||
' ADD COLUMN last_update_timestamp ' ||
'TIMESTAMP WITH TIME ZONE;'
END LOOP;
END $$;
Using this is not my preference because it executes the SQL directly and doesn't allow you
to keep the script afterwards.
There's more...
Earlier I said I'd explain how to run multiple tasks in parallel. Some practical approaches are
possible, with a little discussion.
Making tasks run in parallel can be thought of as subdividing the main task so that we run x2,
x4, x8, and such other subscripts, rather than one large script.
First, you should note that error checking gets worse the more parallel tasks you spawn,
whereas performance improves most for the first few subdivisions. Also, we're often
constrained by CPU, RAM, or I/O resources for intensive tasks. That means that splitting a
main task into two to four parallel subtasks isn't practical without some kind of tool to help us
manage this.
There are two approaches here, depending on the two types of the task, as follows:
F Task consists of many smaller tasks, all roughly the same size
F Task consists of many smaller tasks, where the execution times vary according to the
size/complexity of the database object
If we have lots of smaller tasks, then we can just run out scripts multiple times using a simple
round-robin split of tasks, so that each subscript runs half of the subtasks.
F Script 1: Add WHERE c. oid % 2 = 0
F Script 2: Add WHERE c. oid % 2 = 1
 
Search WWH ::




Custom Search