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 |
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 |
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? |