Implementing cost limit/delays for insert/delete/update/select

From: Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Implementing cost limit/delays for insert/delete/update/select
Date: 2008-08-25 20:39:07
Message-ID: 20080825203906.GA571@hyperion.scode.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <peter(dot)schuller(at)infidyne(dot)com>'
Key retrieval: Send an E-Mail to getpgpkey(at)scode(dot)org
E-Mail: peter(dot)schuller(at)infidyne(dot)com Web: http://www.scode.org

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Grant Finnemore 2008-08-25 20:57:19 Proposal to sync SET ROLE and pg_stat_activity
Previous Message Tom Lane 2008-08-25 20:01:19 Re: IN, BETWEEN, spec compliance, and odd operator names