Re: Parallel bitmap heap scan - Mailing list pgsql-hackers
From | Rafia Sabih |
---|---|
Subject | Re: Parallel bitmap heap scan |
Date | |
Msg-id | CAOGQiiPpSnkuKq+oUK_bvQFg2EPGFPN8RwgxTgBa6HU_kQa3EA@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] Parallel bitmap heap scan (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Parallel bitmap heap scan
|
List | pgsql-hackers |
On Wed, Mar 8, 2017 at 11:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Mar 8, 2017 at 1:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> What I'm using is: >> >>> Configured with: >>> --prefix=/Applications/Xcode.app/Contents/Developer/usr >>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>> Apple LLVM version 7.0.2 (clang-700.1.81) >>> Target: x86_64-apple-darwin14.5.0 >>> Thread model: posix >> >> Hm. I noticed that longfin didn't spit up on it either, despite having >> -Werror turned on. That's a slightly newer version, but still Apple's >> clang: >> >> $ gcc -v >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Apple LLVM version 8.0.0 (clang-800.0.42.1) >> Target: x86_64-apple-darwin16.4.0 >> Thread model: posix >> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > Yeah. I think on my previous MacBook Pro, you could do this without > generating a warning: > > int x; > printf("%d\n", x); > > The compiler on this one detects that case, but that seems to be about > as far as it goes. Recently, on testing TPC-H 300 scale factor I stumbled on to a error for Q6, the test environment is as follows, work_mem = 1GB, shared_buffers = 10 GB, Effective_cache_size = 10GB random_page_cost = seq+page_cost =0.1 The error message is, ERROR: invalid DSA memory alloc request size 1610612740 In case required, stack trace is as follows, #0 errfinish (dummy=0) at elog.c:415 #1 0x0000000010738820 in elog_finish (elevel=20, fmt=0x109115d0 "invalid DSA memory alloc request size %zu") at elog.c:1378 #2 0x0000000010778824 in dsa_allocate_extended (area=0x1001b53b138, size=1610612740, flags=4) at dsa.c:676 #3 0x00000000103a3e60 in pagetable_allocate (pagetable=0x1001b52a590, size=1610612736) at tidbitmap.c:1521 #4 0x00000000103a0488 in pagetable_grow (tb=0x1001b52a590, newsize=33554432) at ../../../src/include/lib/simplehash.h:379 #5 0x00000000103a07b0 in pagetable_insert (tb=0x1001b52a590, key=34962730, found=0x3fffc705ba48 "") at ../../../src/include/lib/simplehash.h:504 #6 0x00000000103a3354 in tbm_get_pageentry (tbm=0x1001b526fa0, pageno=34962730) at tidbitmap.c:1235 #7 0x00000000103a1614 in tbm_add_tuples (tbm=0x1001b526fa0, tids=0x1001b51d22a, ntids=1, recheck=0 '\000') at tidbitmap.c:425 #8 0x00000000100fdf24 in btgetbitmap (scan=0x1001b51c4a0, tbm=0x1001b526fa0) at nbtree.c:460 #9 0x00000000100f2c48 in index_getbitmap (scan=0x1001b51c4a0, bitmap=0x1001b526fa0) at indexam.c:726 #10 0x000000001033c7d8 in MultiExecBitmapIndexScan (node=0x1001b51c180) at nodeBitmapIndexscan.c:91 #11 0x000000001031c0b4 in MultiExecProcNode (node=0x1001b51c180) at execProcnode.c:611 #12 0x000000001033a8a8 in BitmapHeapNext (node=0x1001b5187a8) at nodeBitmapHeapscan.c:143 #13 0x000000001032a094 in ExecScanFetch (node=0x1001b5187a8, accessMtd=0x1033a6c8 <BitmapHeapNext>, recheckMtd=0x1033bab8 <BitmapHeapRecheck>) at execScan.c:95 #14 0x000000001032a194 in ExecScan (node=0x1001b5187a8, accessMtd=0x1033a6c8 <BitmapHeapNext>, recheckMtd=0x1033bab8 <BitmapHeapRecheck>) at execScan.c:162 #15 0x000000001033bb88 in ExecBitmapHeapScan (node=0x1001b5187a8) at nodeBitmapHeapscan.c:667 Please feel free to ask if any more information is required for this. -- Regards, Rafia Sabih EnterpriseDB: http://www.enterprisedb.com/
pgsql-hackers by date: