On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund <and...@anarazel.de> wrote: >> > Why would they have to write the complex query? Wouldn't they just >> > need to run that we wrote for them? > > Then write that query. Verify that that query performs halfway > reasonably fast. Document that it should be run against databases after > subjecting them to tests. That'd address my concern as well.
Here is a first attempt at such a query. It requires that the pageinspect and pg_visibility extensions be installed. SELECT c.oid, v.blkno, array_agg(hpi.lp) AS affect_lps FROM pg_class c, LATERAL ROWS FROM (pg_visibility(c.oid)) v, LATERAL ROWS FROM (heap_page_items(get_raw_page(c.oid::regclass::text, blkno::int4))) hpi WHERE c.relkind IN ('r', 't', 'm') AND v.all_frozen AND (((hpi.t_infomask & 768) != 768 AND hpi.t_xmin NOT IN (1, 2)) OR (hpi.t_infomask & 2048) != 2048) GROUP BY 1, 2 ORDER BY 1, 2; I am not sure this is 100% correct, especially the XMAX-checking part: is HEAP_XMAX_INVALID guaranteed to be set on a fully-frozen tuple? Is the method of constructing the first argument to get_raw_page() going to be robust in all cases? I'm not sure what the performance will be on a large table, either. That will have to be checked. And I obviously have not done extensive stress runs yet. But maybe it's a start. Comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers