Aidan Van Dyk <ai...@highrise.ca> wrote: > And for the "first-hack-that-comes-to-mind", I find my self > pulling out the named fifo trick all the time, and just leaving my > for/loop/if logic in bash writing SQL commands to the fifo, > occasionally getting psql to write an answer to a file that I then > read back in bash.... I'm not clear on exactly what you're proposing there, but the thing I've considered doing is having threads to try to keep a FIFO queue populated with a configurable transaction mix, while a configurable number of worker threads pull those transactions off the queue and submit them to the server. The transactions would need to be scripted in some way such that they could query a value and then use it in another statement, or use flow control for conditional execution or looping. And, of course, there would need to be a way do define conditions under which a transaction would roll back and retry from the beginning -- with the retry being a separate count and the failed attempt not counted in the TPS numbers. It would take that much infrastructure to have a performance test which would give numbers which would correspond well to an actual production load in our environment. It still wouldn't be quite as good as actually logging production activity and playing it back, but it would come pretty close with a lot less work per test. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers