Re: Can we get rid of repeated queries from pg_dump?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: depesz(at)depesz(dot)com
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Can we get rid of repeated queries from pg_dump?
Date: 2021-08-31 00:11:00
Message-ID: 1484548.1630368660@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

[ redirecting to -hackers ]

I wrote:
> I experimented with the attached, very quick-n-dirty patch to collect
> format_type results during the initial scan of pg_type, instead. On the
> regression database in HEAD, it reduces the number of queries pg_dump
> issues from 3260 to 2905; but I'm having a hard time detecting any net
> performance change.

I decided that that patch wasn't too safe, because it applies
format_type() to pg_type rows that we have no reason to trust the
longevity of. I think it could fall over if some concurrent process
were busy dropping a temp table, for example.

So here's a version that just does plain caching of the results
of retail getFormattedTypeName() calls. This visibly adds no
queries that were not done before, so it should be safe enough.
And there can't be any cases that it makes slower, either.

regards, tom lane

Attachment Content-Type Size
cache-format_type-lookups-1.patch text/x-diff 2.4 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2021-08-31 02:57:05 Re: vacuumlo
Previous Message Atul Kumar 2021-08-30 19:41:22 Re: vacuumlo

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2021-08-31 00:15:24 Re: Pg stuck at 100% cpu, for multiple days
Previous Message Peter Smith 2021-08-30 23:32:41 unpack_sql_state not called?