|From:||John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>|
|To:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Cc:||Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, 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 Tue, Feb 5, 2019 at 4:04 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Feb 4, 2019 at 2:27 PM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
> > 1. Earlier, I had a test to ensure that free space towards the front
> > of the relation was visible with no FSM. In , I rewrote it without
> > using vacuum, so we can consider adding it back now if desired. I can
> > prepare a patch for this.
> Yes, this is required. It is generally a good practise to add test (unless it takes a lot of time) which covers new code/functionality.
> > 2. As a follow-on, since we don't rely on vacuum to remove dead rows,
> > we could try putting the fsm.sql test in some existing group in the
> > parallel schedule, rather than its own group is it is now.
This is done in 0001.
> > 3. While looking at 0d1fe9f74e, it occurred to me that I ignored this
> > patch's effects on GetRecordedFreeSpace(), which will return zero for
> > tables with no FSM.
> Right, but what exactly we want to do for it? Do you want to add a comment atop of this function?
Hmm, the comment already says "according to the FSM", so maybe it's
already obvious. I was thinking more about maybe commenting the
callsite where it's helpful, as in 0002.
> > The other callers are in:
> > contrib/pg_freespacemap/pg_freespacemap.c
> > contrib/pgstattuple/pgstatapprox.c
> > For pg_freespacemap, this doesn't matter, since it's just reporting
> > the facts. For pgstattuple_approx(), it might under-estimate the free
> > space and over-estimate the number of live tuples.
> Sure, but without patch also, it can do so, if the vacuum hasn't updated freespace map.
Okay, then maybe we don't need to do anything else here.
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Daniel Gustafsson||2019-02-05 10:09:42||Re: Tighten up a few overly lax regexes in pg_dump's tap tests|
|Previous Message||David Rowley||2019-02-05 09:47:24||Re: Performance issue in foreign-key-aware join estimation|