Prepare enabled pgbench

Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
pgbench?

If not, I can do it myself and if you are interested, I'll send you the
patch.

- Curtis

> Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
> pgbench?

As far as I know, no one is working on that.

> If not, I can do it myself and if you are interested, I'll send you the
> patch.

Thanks. I can commit it for 7.4. BTW, it would be nice if we could
have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
could see how PRPARE/EXECUTE could improve the performance...
--
Tatsuo Ishii

Tatsuo Ishii wrote:
> > Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
> > pgbench?
>
> As far as I know, no one is working on that.
>
> > If not, I can do it myself and if you are interested, I'll send you the
> > patch.
>
> Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> could see how PRPARE/EXECUTE could improve the performance...

We could probably just run before-after patch tests to see the
performance change. I am afraid adding that switch into the code may
make it messy.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> > Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> > have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> > could see how PRPARE/EXECUTE could improve the performance...
>
> We could probably just run before-after patch tests to see the
> performance change. I am afraid adding that switch into the code may
> make it messy.

But one of the purposes of pgbench is examining performance on
different environments, doesn't it? I'm afraid hard coded
PREPARE/EXECUTE makes it harder.
--
Tatsuo Ishii

Tatsuo Ishii wrote:
> > > Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> > > have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> > > could see how PRPARE/EXECUTE could improve the performance...
> >
> > We could probably just run before-after patch tests to see the
> > performance change. I am afraid adding that switch into the code may
> > make it messy.
>
> But one of the purposes of pgbench is examining performance on
> different environments, doesn't it? I'm afraid hard coded
> PREPARE/EXECUTE makes it harder.

I was just thinking that pgbench is for measuring code changes, not for
testing changes _in_ pgbench. Once we know the performance difference
for PERFORM, would we still keep the code in pgbench? Maybe to test
later, I guess.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> > But one of the purposes of pgbench is examining performance on
> > different environments, doesn't it? I'm afraid hard coded
> > PREPARE/EXECUTE makes it harder.
>
> I was just thinking that pgbench is for measuring code changes, not for
> testing changes _in_ pgbench. Once we know the performance difference
> for PERFORM, would we still keep the code in pgbench? Maybe to test
> later, I guess.

My concern is PREPARE/EXECUTE may NOT always improve the
performance. I guess we have very few data to judge PREPARE/EXECUTE is
good or not. Moreover PREPARE/EXECUTE might be improved in the
future. If that happens, keeping that switch would help examining the
effect, no?
--
Tatsuo Ishii

Tatsuo Ishii wrote:
> > > But one of the purposes of pgbench is examining performance on
> > > different environments, doesn't it? I'm afraid hard coded
> > > PREPARE/EXECUTE makes it harder.
> >
> > I was just thinking that pgbench is for measuring code changes, not for
> > testing changes _in_ pgbench. Once we know the performance difference
> > for PERFORM, would we still keep the code in pgbench? Maybe to test
> > later, I guess.
>
> My concern is PREPARE/EXECUTE may NOT always improve the
> performance. I guess we have very few data to judge PREPARE/EXECUTE is
> good or not. Moreover PREPARE/EXECUTE might be improved in the
> future. If that happens, keeping that switch would help examining the
> effect, no?

It would. I was just concerned that having both in there would be a
maintenance headache and would perhaps double the amount of code and
make it complicated. Let see what the author does and we can decide
then.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> > My concern is PREPARE/EXECUTE may NOT always improve the
> > performance. I guess we have very few data to judge PREPARE/EXECUTE is
> > good or not. Moreover PREPARE/EXECUTE might be improved in the
> > future. If that happens, keeping that switch would help examining the
> > effect, no?
>
> It would. I was just concerned that having both in there would be a
> maintenance headache and would perhaps double the amount of code and
> make it complicated. Let see what the author does and we can decide
> then.

Ok.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> could see how PRPARE/EXECUTE could improve the performance...

That is a *must*. Otherwise, you've simply made an arbitrary change
in the benchmark ... which is no benchmark at all.

regards, tom lane

> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> > have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> > could see how PRPARE/EXECUTE could improve the performance...

tom lane replies:
> That is a *must*. Otherwise, you've simply made an arbitrary change
> in the benchmark ... which is no benchmark at all.
>
> regards, tom lane

I will add it as a switched option.

It should be possible to keep most of the code common for the two cases.

- Curtis

Hi Curtis,

Have you had time to get this done?

:-)

Regards and best wishes,

Justin Clift

Curtis Faith wrote:
>>Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>>
>>>Thanks. I can commit it for 7.4. BTW, it would be nice if we could
>>>have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
>>>could see how PRPARE/EXECUTE could improve the performance...
>
>
> tom lane replies:
>
>>That is a *must*. Otherwise, you've simply made an arbitrary change
>>in the benchmark ... which is no benchmark at all.
>>
>> regards, tom lane
>
>
> I will add it as a switched option.
>
> It should be possible to keep most of the code common for the two cases.
>
> - Curtis
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi