Hello, I'd like to have a stab at implementing cost delays, for regular INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for VACUUM and the autovacuum limits; one may have application specific bulk operations that need executing without adverseley affecting latency/throughput of other operations.
I tentatively call this executing statements "nicely". A better naming scheme might be a good idea... The idea would be to introduce two GUC variables: - nice_cost_limit - nice_cost_delay Which would be equivalent to their vacuum_* counterparts. Upon executing an INSERT, UPDATE, DELETE or SELECT, one would optionally specify a "NICELY" modifier to enable nice cost limits for that statement. For example: DELETE NICELY FROM large_table WHERE id < 50000000 In the future I foresee also specifying a nice multiplier of some kind, thus supporting variable niceness on a per-statement basis. To avoid complexity, the initial version would not contain anything similar to the autovacuum balancing of costs between separate vacuum processes. The cost accounting would be entirely local to each backend. Firstly, any opinions on whether this is a good idea, or on whether the above suggestions sound sensible? Implementation: Although the current cost delay support, in terms of variable naming, suggest it is specific to vacuuming, I haven't found anything that is really specific to this. As far as I can tell, an implementaiton would entail: * Adding the GUC variables * Modifying the parser slightly to support the NICELY "modifier" (terminology?) * Modify ExecPlan in backend/executor/execMain.c to contain accounting initialization and cleanup like backend/commands/vacuum.c's vacuum(). * Create an equivalent of the vacuum_delay_point() and call it in each loop iteration in ExecPlan(). And then costmetically, probably rename various things so that non-vacuum specific cost accounting is no longer named as if it were. Does this sound vaguely sensible? Is there an obvious show-stopper I am missing? -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
pgpxJu0qdFRG7.pgp
Description: PGP signature
