Re: pgbench--new transaction type - Mailing list pgsql-hackers

From Greg Smith
Subject Re: pgbench--new transaction type
Date
Msg-id 4E0BFD25.8020207@2ndQuadrant.com
Whole thread Raw
In response to Re: pgbench--new transaction type  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On 06/30/2011 12:13 AM, Jeff Janes wrote:
> One more thought I had, would it make sense to change this from the
> creation of a PL/pgSQL permanent function to instead use the recently
> added DO anonymous block syntax?  I think that would be somewhat
> cleaner about leaving cruft behind in the database.  But it would
> increase the overhead of each outer execution, and would also mean
> that it would not be backwards compatible to run against servers
> before 9.0
>    

I think some measurement of the overhead difference would be needed to 
know for sure about the first part.  I suspect that given the block size 
of 512 now being targeted, that would end up not mattering very much.

pgbench's job is to generate a whole database full of cruft, so I can't 
say I'd find an argument from either side of that to be very 
compelling.  I'm not real busy anymore testing performance of PostgreSQL 
instances from before 9.0 anymore either, so whether this mode was 
compatible with them or not isn't very compelling either.  Just a mixed 
bag all around in those areas.

I would say take a look at what the performance change looks like, and 
see if it turns out to make the patch to pgbench less obtrusive.  The 
main objection against committing this code I can see is that it will 
further complicate pgbench for a purpose not many people care about.  So 
if the DO version ends up with a smaller diff and less impact on the 
codebase, that would likely be a more substantial tie-breaker in its 
favor than any of these other arguments.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: hint bit cache v6
Next
From: Jeff Janes
Date:
Subject: Re: Small patch for GiST: move childoffnum to child