| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | shihao zhong <zhong950419(at)gmail(dot)com>, Atisss hh <125atishprak(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19849: queries fail after ANALYZE with expression stats on arrays |
| Date: | 2026-11-10 22:33:30 |
| Message-ID: | avObuoda1a9JRpBi@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Nov 10, 2026 at 01:53:01PM -0500, Tom Lane wrote:
> Yeah, I didn't love this particular refactorization either. I think
> it'd be nicer to have the values[] and nulls[] arrays totally inside
> the shared function and do the tuple-building within it, as attached.
Including the tuple build in the routine sounds good here. That takes
care of my worries with the previous patch.
> One thing that bugs me slightly about this is that it seems weird to
> be passing starelid and stainherit explicitly while digging staattnum
> out of the VacAttrStats struct. It works, because examine_expression
> is careful to set stats->tupattnum = InvalidAttrNumber, but maybe
> it would be cleaner to pass all three parts of the primary key as
> explicit arguments. Does anyone else feel that way?
None here. Passing down tupattnum as an argument coming from "stats"
also felt a bit strange..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-11-10 22:51:47 | Re: BUG #19836: Backend crash with large hash partition modulus |
| Previous Message | Corey Huinker | 2026-11-10 21:36:28 | Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats |