From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, John Naylor <jcnaylor(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Avoid creation of the free space map for small tables |
Date: | 2018-11-04 00:26:49 |
Message-ID: | 20181104002649.GD1743@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 02, 2018 at 10:38:45AM -0400, Robert Haas wrote:
> I think it's in evidence, in the form of several messages mentioning a
> flag called try_every_block.
>
> Just checking the last page of the table doesn't sound like a good
> idea to me. I think that will just lead to a lot of stupid bloat. It
> seems likely that checking every page of the table is fine for npages
> <= 3, and that would still be win in a very significant number of
> cases, since lots of instances have many empty or tiny tables. I was
> merely reacting to the suggestion that the approach should be used for
> npages <= 32; that threshold sounds way too high.
It seems to me that it would be costly for schemas which have one core
table with a couple of records used in many joins with other queries.
Imagine for example a core table like that:
CREATE TABLE us_states (id serial, initials varchar(2));
INSERT INTO us_states VALUES (DEFAULT, 'CA');
If there is a workload where those initials need to be fetched a lot,
this patch could cause a loss. It looks hard to me to put a straight
number on when not having the FSM is better than having it because that
could be environment-dependent, so there is an argument for making the
default very low, still configurable?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-11-04 00:28:37 | Re: CF app feature request |
Previous Message | Michael Paquier | 2018-11-04 00:17:04 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |