Re: pgbench - refactor init functions with buffers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, David Steele <david(at)pgmasters(dot)net>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - refactor init functions with buffers
Date: 2020-03-28 19:16:21
Message-ID: 29263.1585422981@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-03-28 14:49:31 -0400, Tom Lane wrote:
>> Why? I'm not aware of any intention to deprecate/remove PQExpBuffer,
>> and I doubt it'd be a good thing to try. It does some things that
>> StringInfo won't, notably cope with OOM without crashing.

> - code using it cannot easily be shared between frontend/backend (no
> memory context integration etc)

True, but also pretty irrelevant for pgbench and similar code.

> - most code does *not* want to deal with the potential for OOM without
> erroring out

Fair point.

> - it's naming is even more confusing than StringInfo

Eye of the beholder ...

> - it introduces dependencies to libpq even when not needed

Most of our FE programs do include libpq, and pgbench certainly does,
so this seems like a pretty irrelevant objection as well.

> - both stringinfo and pqexpbuffer are performance relevant in some uses,
> needing to optimize both is wasted effort

I'm not aware that anybody is trying to micro-optimize either. Even
if someone is, it doesn't imply that they need to change both.

> - we shouldn't expose everyone to both APIs except where needed - it's
> stuff one has to learn

That situation is unlikely to change in the foreseeable future.
Moreover, using both APIs in one program, where we were not before,
makes it worse not better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2020-03-28 19:28:49 Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Previous Message Tom Lane 2020-03-28 19:07:55 Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction