Message-ID: <5486196E.4080602@aklaver.com>
Date: Mon, 08 Dec 2014 13:34:38 -0800
From: Adrian Klaver <adrian.klaver@aklaver.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tim Dudgeon <tdudgeon.ml@gmail.com>, pgsql-sql@postgresql.org,
 pgsql-performance@postgresql.org
Subject: Re: querying with index on jsonb slower than standard column.
 Why?
References: <5484DBDA.6090405@gmail.com> <5484EEA7.1030403@aklaver.com>
 <5484F437.2080402@gmail.com> <16147.1418002090@sss.pgh.pa.us>
 <5485C449.4020204@aklaver.com> <26002.1418053572@sss.pgh.pa.us>
 <5485C8BA.7040704@aklaver.com> <5485D584.8080105@aklaver.com>
 <27877.1418057764@sss.pgh.pa.us> <3936.1418071989@sss.pgh.pa.us>
 <548614C8.90203@aklaver.com> <4746.1418073776@sss.pgh.pa.us>
In-Reply-To: <4746.1418073776@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

On 12/08/2014 01:22 PM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> I redid the test on my 32-bit machine, setting work_mem=16MB, and I got
>> comparable results to what I saw on the 64-bit machine. So, what I am
>> still am puzzled by is why work_mem seems to make the two paths
>> equivalent in time?:
>
> If work_mem is large enough that we never have to go through
> tbm_lossify(), then the recheck condition will never be executed,
> so its speed doesn't matter.

Aah, peeking into tidbitmap.c is enlightening. Thanks.

>
> (So the near-term workaround for Tim is to raise work_mem when
> working with tables of this size.)
>
> 			regards, tom lane
>
>


-- 
Adrian Klaver
adrian.klaver@aklaver.com


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql