I wrote:
> Adrian Klaver writes:
>> Seems work_mem is the key:
> Fascinating. So there's some bad behavior in the lossy-bitmap stuff
> that's exposed by one case but not the other.
Meh. I was overthinking it. A bit of investigation with oprofile exposed
the true cause of the problem: whenever
On 12/08/2014 12:53 PM, Tom Lane wrote:
> I wrote:
>> Adrian Klaver writes:
>>> Seems work_mem is the key:
>
>> Fascinating. So there's some bad behavior in the lossy-bitmap stuff
>> that's exposed by one case but not the other.
>
> Meh. I was overthinking it. A bit of investigation with opro
Adrian Klaver 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 neve
On 12/08/2014 01:22 PM, Tom Lane wrote:
Adrian Klaver 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 w
On 08/12/2014 18:14, Adrian Klaver wrote:
Recheck Cond: data ->> 'assay1_ic50'::text))::double precision > 90::double
precision) AND (((data ->> 'assay2_ic50'::text))::double precision < 10::double
precision))
>
>which means we have to pull the JSONB value out of the tuple, search
>it to fi
On Sat, Dec 6, 2014 at 7:08 AM, Bruce Momjian wrote:
> On Wed, Nov 5, 2014 at 12:09:16PM -0600, Merlin Moncure wrote:
>> effective_io_concurrency 1: 46.3 sec, ~ 170 mb/sec peak via iostat
>> effective_io_concurrency 2: 49.3 sec, ~ 158 mb/sec peak via iostat
>> effective_io_concurrency 4: 29.1 s
