[Bizgres-general] Transactional Statement Queuing - Queue Design 1

[Mark Kirkwood]

Mark Kirkwood wrote:
> A lively off-list discussion was triggered by the 'pre-initial' version 
> of this patch (nothing like having something concrete to pound on), 
> culminating in the conclusion that a significant revision of the 
> *original* proposal was in order - I'll summarize:
> 
> 1/ Queuing need to be at the statement level (at least), as opposed to 
> the transaction level.
> 
> 2/ The queuing mechanism needs to be extensible.
>

In my summary I missed one point:

3/ Avoid changing the lightweight lock manager.

Thus the attached patch in the previous mail is for historical interest 
only.

Additionally, some more detail on the summary points:

Re 1:

Transaction level locking is too coarse a grain, and suffers from 
deficiencies like sessions being unable to execute low cost statements 
because other sessions are running high cost ones or (worse) are idle 
holding the transaction lock!


Re 2:

At transaction start (or even the start of the first statement in a 
transaction) is is not possible to determine what resources subsequent 
statements are going to require. This makes it almost impossible to 
implement additional features based on those statements themselves.


Re 3:

Changes here can have far reaching consequences for every aspect of 
server performance (and reliability). For instance even though the 
(prev) attached patch changed little of the code paths for exclusive and 
shared lock modes, it adds a 4 byte field to the LWLock object, and thus 
  changes its padded size from 16->32 bytes (padding is for cpu cache 
optimization). Now this *may* have an effect (so would require some 
testing at least).

Cheers

Mark