Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Doug Lawry asked what the pfsc_boost scheduled task in IDS 14.10.FC2 does. SangGyu Jeong linked it to the Partition Free Space Cache. Art Kagel explained it populates a cache of free space on pages for variable-length-row tables when MAX_FILL_DATA_PAGES is used, avoiding page scans on busy insert/delete tables. Doug also noted InformixHQ will not accept zero for AUS_PDQ; a ph_threshold update works.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Doug Lawry — source: IBM Community (ConnectedCommunity.org) Informix forum
Does anyone know what this scheduled task is in IDS 14.10.FC2? It executes C UDR adm
_
pfsc_boost
an
d the description is "PFSC Boost", so no clues there...
Also found a minor bug in InformixHQ that you can't specify zero in Automated Update Statistics / Configuration / AUS_PDQ which would cause noise in the message log for restricted editions. You can set it to zero using Task Scheduler /
Auto Update Statistics Refresh / Parameters, though. Alternatively:
UPDATE ph_threshold SET value = 0 WHERE name = 'AUS_PDQ';------------------------------
Regards,
Doug Lawry
------------------------------
#Informix
↪ replying to Doug Lawry
SangGyu Jeong — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi Doug,
This feature is available since 14.10.xc2.
The output of the onstat -g cfg command shows that the feature is enabled by default.
The pfsc_boost task seems to be related to this.
I found a description of that feature (PFSC, Partition Free Space Cache) in JC Lengyel's IIUG2019 conference presentation.
And it could not modify the AUS_PDQ to 0 as shown below in InformixHQ v2. Thank you for sharing the information.
------------------------------
SangGyu Jeong
Software Engineer
Infrasoft
Seoul Korea, Republic of
------------------------------
↪ replying to Doug Lawry
Art Kagel — source: IBM Community (ConnectedCommunity.org) Informix forum
Since MAX_FILL_DATA_PAGES was implemented there has been a problem with it for tables with variable length columns, high insert activity, and frequent deletes. Review: Before MAX_FILL_DATA_PAGES and when it is disabled, Informix will only place a new variable length row on a page if the maximum length of the row would fit. This could cause wasted storage up to 50% for some tables. When this feature is enabled Informix tries to place new variable length rows onto pages that have room for that particular row so long as 10% is free on the page afterwards for rows to expand into without having to be moved to a forwarding page. On a table with deletes that might mean checking many many pages before finding a home for the new row and tends to severely slow down systems that perform many many inserts to these tables. That is because the bitmap pages only tell the engine whether a page is full, nearly full, half full, or empty not how much space is left on it. So, in 14.10.FC2 they implemented a cache recording the free space on not-full pages for variable length tables so the engine just has to check the cache instead of having to read many many pages into memory to check their free space.
The task manager task that you are seeing, Doug, is how the cache gets populated. It is enabled by default. The feature to use the cache or not to is controlled by the new ONCONFIG parameter PFSC which is set to '1' - ON by default.
------------------------------
Art Kagel
------------------------------
↪ replying to SangGyu Jeong
Doug Lawry — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks, SangGyu. For those who haven't seen it,
JC Lengyel's
presentation says:
Boosted Partition Free Space Cache
Applicable only when MAX_FILL_DATA_PAGES is set, and for tables that have variable-length rows.
Note that a compressed table has variable-length rows.
The "fullness" of every data page with room for another row is tracked in memory.
Circumvents bitmap scans, which have the potential to be unproductive.
YMMV [your mileage may vary] depending on schema and typical row size.
This feature is available in 14.10.xC2.
------------------------------
Doug Lawry
------------------------------
↪ replying to Art Kagel
Doug Lawry — source: IBM Community (ConnectedCommunity.org) Informix forum
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.