Mark INFORMATION_SCHEMA_TSQL.TABLE_CONSTRAINTS_INTERNAL() function as PARALLEL SAFE

[sumitj824]

Description

The INFORMATION_SCHEMA_TSQL.TABLE_CONSTRAINTS_INTERNAL() function was recently introduced but not marked as PARALLEL SAFE. This prevented the query optimizer from utilizing parallel plans in queries involving this function, leading to suboptimal performance for certain operations.

By marking the function as PARALLEL SAFE, we enable the use of parallel query execution plans, which can significantly improve performance for large datasets.

Signed-off-by: Sumit Jaiswal [email protected]

Issues Resolved

Task: BABEL-5427

Performance Testing

Query:

SELECT 
    tc.TABLE_SCHEMA, 
    tc.TABLE_NAME, 
    kcu.COLUMN_NAME, 
    c.DATA_TYPE 
FROM 
    INFORMATION_SCHEMA.TABLE_CONSTRAINTS tc 
JOIN 
    INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu 
    ON tc.CONSTRAINT_SCHEMA = kcu.CONSTRAINT_SCHEMA 
    AND tc.CONSTRAINT_NAME = kcu.CONSTRAINT_NAME 
JOIN 
    INFORMATION_SCHEMA.COLUMNS c 
    ON kcu.TABLE_SCHEMA = c.TABLE_SCHEMA 
    AND kcu.TABLE_NAME = c.TABLE_NAME 
    AND kcu.COLUMN_NAME = c.COLUMN_NAME 
WHERE 
    tc.CONSTRAINT_TYPE = 'PRIMARY KEY';

Before : 50187 ms
After: 47285 ms

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.

For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[coveralls]

Pull Request Test Coverage Report for Build 12504188892

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 74.855%

---

Totals
Change from base Build 12502179127:	0.0%
Covered Lines:	46569
Relevant Lines:	62212

---

💛 - Coveralls

[tanscorpio7]

I am wondering if the test failure is because of a similar issue like #2262, we initialized current_db_name for babelfish parallel workers in this PR but did not initialize current_db_id, which seems strange.
Could you try setting current_db_id as well in set_cur_db_name_for_parallel_worker ?