On 2026-Jan-20, Tatsuro Yamada wrote:
> The error in the query has been fixed, and the execution times were
> measured again.
> As a result, there was no significant difference in execution time
> between the two queries (see the attached test_result2.txt).
> When comparing the cost of the top node, the original query has a
> slightly lower cost, so I decided to keep it as is.
Yeah, these results match my own tests -- the query I proposed is a bit
slower. Not by a lot, but measurably so. (I did ran my disk full by
running pgbench with the two queries in separate files and the one
million constraints; temp files for sort are quite large. My query is
pretty consistently reported to be slower than the other anyway.)
> List of constraints
> Schema | Table | Type | Name
> --------+-------+-----------+----------------------------
> public | con_c | NOT NULL | con_c_primary_col_not_null
> public | con_c | PK | con_c_pkey
> public | con_p | CHECK | con_p_check_col_check
> public | con_p | EXCLUSION | con_p_exclusion
> public | con_p | FK | con_p_foreign_col_fkey
> public | con_p | NOT NULL | con_p_notnull_col_not_null
> public | con_p | NOT NULL | con_p_primary_col_not_null
> public | con_p | PK | con_p_pkey
> public | con_p | TRIGGER | con_p_trigger
> public | con_p | UNIQUE | con_p_unique_col_key
> (10 rows)
>
> What do you think?
Looks good. I think the constraint types ought to be lower-case and
fully spelled out, with not-null having an hyphen as discussed
elsewhere (though I couldn't find the reference), so
not-null
primary key
exclusion
check
foreign key
unique
trigger
I wonder if we should mark temporal constraints especially. (So
"temporal primary key", etc). Without thinking too much about it, my
impression is that it'd be useful.
I didn't look at the patch closer, apologies.
Thanks
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")
