|From:||John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>|
|To:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Cc:||Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: WIP: Avoid creation of the free space map for small tables|
|Views:||Raw Message | Whole Thread | Download mbox|
On Sat, Jan 26, 2019 at 2:14 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sat, Jan 26, 2019 at 5:05 AM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
> > So, in v19 we check pg_class.relpages and if it's
> > a heap and less than or equal the threshold we call stat on the 0th
> > segment to verify.
> Okay, but the way logic is implemented appears clumsy to me.
> The function transfer_relfile has no clue about skipping of FSM stuff,
> but it contains comments about it.
Yeah, I wasn't entirely happy with how that turned out.
> I think there is some value in using the information from
> this function to skip fsm files, but the code doesn't appear to fit
> well, how about moving this check to new function
For v21, new_cluster_needs_fsm() has all responsibility for obtaining
the info it needs. I think this is much cleaner, but there is a small
bit of code duplication since it now has to form the file name. One
thing we could do is form the the base old/new file names in
transfer_single_new_db() and pass those to transfer_relfile(), which
will only add suffixes and segment numbers. We could then pass the
base old file name to new_cluster_needs_fsm() and use it as is. Not
sure if that's worthwhile, though.
> The order in which relkind and relpages is used in the above code is
> different from the order in which it is mentioned in the query, it
> won't matter, but keeping in order will make look code consistent. I
> have made this and some more minor code adjustments in the attached
> patch. If you like those, you can include them in the next version of
> your patch.
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Thomas Munro||2019-01-27 22:10:33||Emacs vs pg_indent's weird indentation for function declarations|
|Previous Message||Mark Dilger||2019-01-27 20:53:22||Re: "SELECT ... FROM DUAL" is not quite as silly as it appears|