Am 13.09.24 um 17:34 schrieb Wong, Kam Fook (TR Technology):
We have a flavor of this type of query with long in-list/bind variables (see below). We notice that some of the bind variables come in as 0 which causes the optimizer to choose to full scan two of the following 3 tables. One thought to fix a full table scan is to chop off the not-needed bind variables (proven to work after some tests). But my other worry is will cause parsing issues because the app will be executing > 100k/sec with this type of query. I am an Oracle DBA, and this change for sure will generate a different query id. Which in turn generates tons of extra parsing to the DB because all soft and hard parsing occurs at the DB level. But my understanding for Postgres is parsing occurs at the client jdbc level. Am I understanding this correctly? In summary/my concern: 1) Where does query parsing occur? 2) Will this cause extra parsing to the posgress DB? Any pg system table to measure parsing?
You can simplify the query to a single parameter by passing the list of values as an array: SELECT abc, efg from DOCLOC a, COLLECTION b WHERE a.colum1 = ANY($1) AND a.COLLECTION_NAME=b.DOCLOC.COLLECTION_NAME AND a.DOCLOC.STAGE_ID=(SELECT MAX (STAGE_ID) FROM COLLECTION_PIT WHERE COLLECTION_PIT.COLLECTION_NAME=a.COLLECTION_NAME AND COLLECTION_PIT.PIT_ID<=$1001 AND COLLECTION_PIT.STAGE_CODE=$2) You can then pass the array using PreparedStatement.setArray() This has the additional advantage that you don't need to build the query dynamically and there is only a single statement to be parsed. I don't think Postgres distinguishes between soft and hard parses as it doesn't cache plans as aggressively as Oracle.