On Thu, Jun 06, 2019 at 04:40:53PM -0400, Robert Haas wrote: > It looks to me as though any table AM that uses the relation forks > supported by PostgreSQL in a more or less normal manner is likely to > require an implementation of the relation_size callback that is > identical to the one for heap, and an implementation of the > estimate_rel_size method that is extremely similar to the one for > heap. The latter is especially troubling as the amount of code > duplication is non-trivial, and it's full of special hacks. > > Here is a patch that tries to improve the situation. I don't know > whether there is some better approach; this seemed like the obvious > thing to do.
Looks like a neat split. "allvisfrac", "pages" and "tuples" had better be documented about which result they represent. + * usable_bytes_per_page should contain the approximate number of bytes per + * page usable for tuple data, excluding the page header and any anticipated + * special space. [...] +table_block_estimate_rel_size(Relation rel, int32 *attr_widths, + BlockNumber *pages, double *tuples, + double *allvisfrac, + Size overhead_bytes_per_tuple, + Size usable_bytes_per_page) Could you explain what's the use cases you have in mind for usable_bytes_per_page? All AMs using smgr need to have a page header, which implies that the usable number of bytes is (BLCKSZ - page header) like heap for tuple data. In the AMs you got to work with, do you store some extra data in the page which is not used for tuple storage? I think that makes sense, just wondering about the use case. -- Michael
signature.asc
Description: PGP signature
