| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> | 
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> | 
| Subject: | Re: Switch to multi-inserts for pg_depend | 
| Date: | 2020-08-14 18:23:16 | 
| Message-ID: | 20200814182316.GA26549@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2020-Aug-14, Michael Paquier wrote:
> Regarding the maximum number of slots allocated.  Do people like the
> current approach taken by the patch to do a single loop of the
> dependency entries at the cost of more allocating perhaps too much for
> the array holding the set of TupleTableSlots (the actual slot
> initialization happens only if necessary)?  Or would it be preferred
> to scan twice the set of dependencies, discarding pinned dependencies
> in a first scan to build the list of dependencies that would be
> inserted?  This way, you can know the exact amount memory to allocated
> for TupleTableSlots, though that's just 64B for each one of them.
It seems a bit silly to worry about allocating just the exact amount
needed; the current approach looked fine to me.  The logic to keep track
number of used slots used is baroque, though -- that could use a lot of
simplification.
-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-08-14 18:50:32 | Loose ends after CVE-2020-14350 (extension installation hazards) | 
| Previous Message | Alvaro Herrera | 2020-08-14 17:30:08 | Re: Dependencies for partitioned indexes are still a mess |