>> nathan > > > You're both right. Currently, we fetch extended stats one at a time, thus > there's no _immediate_ need to do so. > > But "why wait until there is a crisis" is solid reasoning and for that I had > already coded up the change. >I did have one small problem in that Michael Paquier had hoped that we could >get the expr index (-1, -2, etc) on the expressions > as that was something that we at least briefly thought we'd need for > importing expression statistics. However the existing query > uses a SELECT unnest(a), unnest(b) pattern in it, and WITH ORDINALITY is not > allowed, and the workarounds I found seemed a > bit tortured. Hence, I decided to leave that out so as not to distract from > the now accepted patch, and with that out of the way > I'll happily inflict that tortured SQL on y'all.
Can we add the tableid for now (see 0003) and follow-up with another thread with the sql changes to pg_dump? I also corrected v2-0001. The docs were still referencing "starlid" instead of "tableid" -- Sami Imseih Amazon Web Services (AWS)
v3-0002-pg_dump-Use-tableid-in-getAttributeStats.patch
Description: Binary data
v3-0003-Add-tableid-column-to-pg_stats_ext-and-pg_stats_e.patch
Description: Binary data
v3-0001-Add-tableid-and-attnum-columns-to-pg_stats.patch
Description: Binary data
