pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>
To: Edmund Horner <ejrh00@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Tid scan improvements
Date: Thu, 22 Nov 2018 19:03:21 +0100
Message-ID: <0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com> (raw)
In-Reply-To: <CAKJS1f9TGbBMNsDK+wXtGpVL2=73cmB9=NBxUk9Wp9OH59kg7Q@mail.gmail.com>
References: <CAMyN-kB-nFTkF=VA_JPwFNo08S0d-Yk0F741S2B7LDmYAi8eyA@mail.gmail.com>
	<CAMyN-kCknpsgHt8eP=jeYMGMU=suRAoZ38CoRJB2fxKTKa52gw@mail.gmail.com>
	<CAKJS1f8FyS51b6j++qShP_av5Kq1oq83t16ALPftPm4F0BbqkQ@mail.gmail.com>
	<CAMyN-kCCjuLR=guOHBbD66BE4EuiDe8R5mDrmBJOySntdUS6Xg@mail.gmail.com>
	<CAKJS1f-VsLvQa45yPSSSagFq7VoG-MREDaddJiLt=82gX2WQcg@mail.gmail.com>
	<CAMyN-kBDks3CaALvhCd-KokpygQjO6-1pQ+vnv6Yq6EZUwccUg@mail.gmail.com>
	<CAMyN-kAO-bc5pqgRp1vZ=gFmVjbEQfM7Anikkm6PPDDAekH2Nw@mail.gmail.com>
	<CAKJS1f8Ap6cFKeBbTnHXpOcgq5iXV1UhwA7ZiP4fxxx1LArbwQ@mail.gmail.com>
	<CAMyN-kBRYy=DV3oQ0TD6pJYvNg1oHSTXdCTe94XJGOpJK1GeAA@mail.gmail.com>
	<CAMyN-kB6+KTyH3TQqoLLbNtj2t4AZr8RMHUU0yzxp429o5PyDw@mail.gmail.com>
	<CAKJS1f9+etR1VGkqp=hkGWn3EofWJVFnjKaTpHZva2PKhALdng@mail.gmail.com>
	<CAMyN-kCLxCo=rbysFRM=Ouarp+xd_b=oP26+tr1yXe3C9k89OQ@mail.gmail.com>
	<CAMyN-kDNyqy2RUGn53GnoS1shdB5TYhif9OpGFFkOb7z=za2eQ@mail.gmail.com>
	<CAKJS1f9TGbBMNsDK+wXtGpVL2=73cmB9=NBxUk9Wp9OH59kg7Q@mail.gmail.com>

On 11/22/18 8:41 AM, David Rowley wrote:
 >
> ...
> 
> 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the
> allocation until it reaches the required size. See how
> MakeSharedInvalidMessagesArray() does it.  Doing it this way ensures
> we always have a power of two sized array which is much nicer if we
> ever reach the palloc() limit as if the array is sized at the palloc()
> limit / 2 + 1, then if we try to double it'll fail.  Of course, it's
> unlikely to be a problem here, but... the question would be how to
> decide on the initial size.
> 

I think it kinda tries to do that in some cases, by doing this:

     *numAllocRanges *= 2;

     ...

     tidRanges = (TidRange *)
         repalloc(tidRanges,
                  *numAllocRanges * sizeof(TidRange));

The problem here is that what matters is not numAllocRanges being 2^N, 
but the number of bytes allocated being 2^N. Because that's what ends up 
in AllocSet, which keeps lists of 2^N chunks.

And as TidRange is 12B, so this is guaranteed to waste memory, because 
no matter what the first factor is, the result will never be 2^N.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




view thread (97+ messages)  latest in thread

Message-ID: <0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com>
Permalink:  ../0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com/
Also on:    postgresql.org/message-id/0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, david.rowley@2ndquadrant.com, ejrh00@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Tid scan improvements
  In-Reply-To: <0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox