omic_init_u32(>refcount, 0);
>
> Dilip, please also provide a proposed commit message describing what
> this is fixing. Is it just the TBM_EMPTY case, or is there anything
> else?
Okay, I have added the commit message in the patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.e
On Thu, Mar 16, 2017 at 5:14 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> pg_atomic_write_u32_impl(val=0) at generic.h:57, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>> * frame #0: 0x000100caf314 postgres`tbm_p
the code if there are the similar mistake at
other places. Soon I will post the patch. Thanks for the help.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 16, 2017 at 5:02 AM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> After above fix, I am not able to reproduce. Can you give me the
> backtrace of the crash location or the dump?
>
> I am trying on the below commit
>
> commit c5832346625af4193b1242e57e7d13e66a
dump?
I am trying on the below commit
commit c5832346625af4193b1242e57e7d13e66a220b38
Author: Stephen Frost <sfr...@snowman.net>
Date: Wed Mar 15 11:19:39 2017 -0400
+
https://www.postgresql.org/message-id/attachment/50164/brin-correlation-v3.patch
+ fix_tbm_empty.patch
--
Regards,
tch Robert mentioned that we might
need to handle the TBM_EMPTY and I told that since we are not handling
in non-parallel mode so we don't need to handle here as well. But, I
was wrong. So the problem is that if state is not TBM_HASH then it's
directly assuming TBM_ONE_PAGE which is completely
n access
> more information.
>
> [1]
> https://www.postgresql.org/message-id/attachment/50164/brin-correlation-v3.patch
With my test case, I could not crash even with this patch applied.
Can you provide your test case?
(table, index, data, query)
--
Regards,
Dilip Kumar
EnterpriseDB:
if either tuple is invalid memory(but I
think it's not because we have already accessed this memory in above
if check) or dtup is invalid (this is also not possible because
brin_new_memtuple has already accessed this).
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent
On Wed, Mar 15, 2017 at 8:51 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>> I can try to provide a test case, if that wouldn't be enough to spot
>> the problem.
>
> Thanks for reporting, I am looking into this. Meanwhile, if you can
> provide the reproducible test c
ating the issue will be
faster.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hmm, It seems that es->lazyEval is not set properly, Ideally, it
should be set true only if it's lazy evaluation but in this case, it's
used for identifying the tupcount as well. IMHO, it should be fixed.
Any other opinion on this?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterp
On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> I slightly modified your query to reproduce this issue.
>
> explain analyze select * from r1 where value<555;
>
> Patch is attached to fix the problem.
I forgot to mention the cause of
On Thu, Mar 9, 2017 at 9:37 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>> =# create table r1(value int);
>> CREATE TABLE
>> =# insert into r1 select (random()*1000)::int from
>> generate_Series(1,100);
>> INSERT 0 100
>> =# create inde
e index on r1 using brin(value);
> CREATE INDEX
> =# set enable_seqscan=0;
> SET
> =# explain select * from r1 where value=555;
I am looking into the issue, I have already reproduced it. I will
update on this soon.
Thanks for reporting.
--
Regards,
Dilip Kumar
EnterpriseDB: http:/
o is also roll in the increment to prefetch
> pages in there, so that you don't have to reacquire the spinlock after
> calling PrefetchBuffer:
>
> bool do_prefetch = false;
> SpinLockAcquire(>mutex);
> if (pstate->prefetch_pages < pstate->prefetch_targ
y use it unless
we stop the execution because of some limit clause.
>
>> Fixed
>
> Committed 0001.
Thanks
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Tue, Mar 7, 2017 at 10:10 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>> It's not about speed. It's about not forgetting to prefetch. Suppose
>> that worker 1 becomes the prefetch worker but then doesn't return to
>> the Bitmap Heap Scan node for a long time b
e should not do anything
>> if jointype was JOIN_UNIQUE_INNER, so fixed that also.
>
> This version looks fine to me, so committed.
Thank you.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
issed this part. I will fix this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
r.
Done
Apart from this, there was one problem in match_unsorted_outer (in
v10), Basically, if inner_cheapest_total was not parallel_safe then I
was always getting parallel safe inner. But, we should not do anything
if jointype was JOIN_UNIQUE_INNER, so fixed that also.
--
Regards,
Dilip Kumar
E
by
multiple processes will it be any faster? Or you are thinking that at
least we can make BufTableLookup call parallel because that is not an
async call.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
f (DsaPointerIsValid(node->pstate->prefetch_iterator))
> + dsa_free(dsa, node->pstate->prefetch_iterator);
As per latest code, both should be calling to tbm_free_shared_area
because tbm_free_shared_area is capable of handling that. My silly
mistake. I will fix i
_cheapest_path_for_pathkeys" for complete pathlist and if
we decide not to call consider_parallel_mergejoin if the cheapest
parallel safe path in innerrel->cheapest_parameterized_paths is NULL
then it will not be fair (we might have some parallel safe paths in
innerrel->pathlist).
--
Reg
op and consider_parallel_mergejoin calls
> inside the if-block.
Done
>
> You could Assert(nestjoinOK) instead of testing it, although I guess
> it doesn't really matter.
left as it is.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
parallel_mergejoin_v9.patch
Description:
> to be adding rather than removing complexity after this refactoring.
0003 is rebased after this commit.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0003-parallel-bitmap-heapscan-v7.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hack
oceed with this paths if this is not directly parameterized by
outer?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
other
> better way to handle the same.
Done that way.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
parallel_mergejoin_v8.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
s covering more ordered keys. Still, it's
hard to argue what it better because we can always say that if we try
only cheapest parallel safe path we will generate fewer paths.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
re. They'll be in the same cache line, so it won't be much faster
> than having one mutex, and the state mutex won't be acquired very
> often so you won't really gain anything anyway. I think you can just
> merge the mutexes into one called 'mutex'.
Done.
>
> +
ease for this patch at
> high worker counts.
I think there is some confusion, if you notice, below code will avoid
calling pbms_is_leader for every tuple.
It will be called only first time. And, after that node->inited will
be true and it will directly jump to start_iterate for subsequent
calls. Am I missi
e. already in the
parallel mode we don't allow to launch worker?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ch status in CF app (to Needs Review) whenever
> you post a new patch. I could see that your other patch also needs a
> similar update in CF app.
Will changes, Thanks.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
parallel_mergejoin_v7.patch
Description: Binary
at it appears more
specific to insert I think.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ndling related to
> unique outer and full joins, so it is better to mention that in the
> function comments, something like "unlike above function, this
> function doesn't expect to handle join types JOIN_UNIQUE_OUTER or
> JOIN_FULL" and add Assert for both of those types.
which is not parallel safe) but at
the cost of considering some extra paths. What is your thought on
this?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
PROPARALLEL_UNSAFE);
> }
Ok, I see. But, the problem with PL functions is that plan might have
already generated in previous execution of the function and during
that time outer query might not be running in parallel. So I think we
may need some check during execution time as well?
--
Regar
On Thu, Feb 23, 2017 at 8:58 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> Few more comments.
> 1.I don't see any check in the code which will prevent the parallel
> execution of the query inside a function if its called from a DML
> statement.
> e.g. If we use a f
if the outer select is running in parallel,
then the function called from there should not run anything in
parallel? This may allow worker launching another set of workers. Am
I missing something?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing
te->readonly_func, 0);
+ }
The last parameter of SPI_execute is tuple count, not cursorOption,
you need to fix this. Also, this is crossing the 80 line boundary.
---
Any specific reason for not changing SPI_execute_with_args, EXECUTE
with USING will take this path.
--
Regards,
D
On Mon, Feb 20, 2017 at 11:18 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 5:55 AM, Thomas Munro
> <thomas.mu...@enterprisedb.com> wrote:
>> On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>>> So basical
t node on top of the Gather and Materialize is obviously
cheaper than the Sort.)
MergeJoin
-> Index Scan
-> Materialize
-> Gather Merge (Does not support mark/restore)
->Parallel Index Scan
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pg
ous
> iteration, which means that any allocations will also hang around.
Yes right, they hang around. But, during rescan
(ExecReScanBitmapHeapScan) we can free all these DSA pointers ? That
mean before reallocating the DSA pointers we would have already got
rid of the old ones.
--
Re
ces the reference count to 0
> calls dsa_free on the DSA pointers for pagetable, spages, and schunks.
> (Also, if a TIDBitmap is freed before iteration begins, it frees the
> DSA pointer for the pagetable only; the others won't have values yet.)
--
Regards,
Dilip Kumar
EnterpriseDB: http://www
On Sat, Feb 18, 2017 at 10:45 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> in 0002:
> - Improved comments.
> - Code refactoring in BitmapHeapNext.
> - Removed local tbm creation in BitmapHeapNext : as per new tidbitmap
> it's of no use.
I have observed one problem w
to zero, the user doesn't want a parallel scan.
> */
>
> If we got zero? There aren't multiple limits mentioned anywhere
> nearby, so this reads oddly.
Removed
>
> +/*
> + * It may be possible to amortize some of the I/O cost, but probably
> +
put->offsets[ntuples++] = (OffsetNumber) off;
> +off++;
> +w >>= 1;
> +}
> +}
> +}
>
> Similarly, this looks like it could be refactored into a shared static
> inline function as well, instead of dupli
one.
One solution to this could be that I keep two dsa_pointer in TBM, one
point to old memory and another to new. (After this here we will get
the same problem of relptr_access because now we will have first entry
pointer is same as base pointer)
Please provide your thought.
--
Regards,
D
||
+ compare_path_costs(innerpath, cheapest_total_inner,
+ TOTAL_COST) < 0))
In this comparison, we were only checking if innerpath is cheaper than
the cheapest_total_inner then generate path with this new inner path
as well. Now, I have added one more check if cheapest_total_inner was
not par
cate(pagetable_hash *pagetable, Size size)
>
> Function name and comments mismatch?
Fixed.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0001-tidbitmap-support-shared-v2.patch
Description: Binary data
0002-parallel-bitmap-heapscan-v2.patch
Description: Binary data
--
ded from frontend code"
#endif
Is there any other solution to this ?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ableEntry.
I have implemented 2nd (in the initial versions I implemented with 1st).
Note: Patch is also rebased on top of guc_parallel_index_scan_v1.patch
from Parallel Index Scan thread[1]
[1]
https://www.postgresql.org/message-id/CAA4eK1%2BTnM4pXQbvn7OXqam%2Bk_HZqb0ROZUMxOiL6DWJYCyYow%40mail.gmail.com
-
private_data = hashtable;
> +hashtable->hashtab = tuplehash_create(tablecxt, nbuckets, hashtable);
Okay, will go ahead as you suggested. Patch attached for the same.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
hash_create_fix.patch
Description: Binary data
--
Se
ctions.
The solution is simplehash.h, should always declare it, and provide
the definitions only if SH_USE_NONDEFAULT_ALLOCATOR is not defined.
Attached patch does that.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
hash_allocate_fix.patch
Description: Binary data
--
le_hash *pagetable, Size size)
{
TIDBitmap *tbm = pagetable->ctx;
So Is it expected to do like I explained above, or we missed to have
an arg parameter to SH_CREATE as well as in SH_TYPE structure or there
is some other way you have in mind?
--
Regards,
Dilip Kumar
EnterpriseDB: http://ww
having a reference to the TBMIterateResult so
we should not have any problem in passing this reference to the
tbm_shared_iterate. I think this one looks better than what I
explained above.
Please suggest.
>
> 4. Add a new function TBMIterateResult
> *tbm_shared_iterate(TBMSharedIterato
we should rename the functions to element_allocate,
> element_free, and element_allocator_ctx, or something like that. The
> current names aren't capitalized consistently with other things in
> this module, and putting the word "element" in there would make it
> more clear what t
cost anything (except that
> SH_CREATE will grow a slightly longer argument sequence).
>
> I think maybe we should rename the functions to element_allocate,
> element_free, and element_allocator_ctx, or something like that. The
> current names aren't capitalized consistently with other things in
> this
e
>
>
> +typedef struct
> +{
> + TIDBitmap *tbm; /* TIDBitmap we're iterating over */
> + int spageptr; /* next spages index */
> + int schunkptr; /* next schunks index */
> + int schunkbit; /* next bit to check in current schunk */
> + TBMIterateResult output; /* M
On Tue, Jan 24, 2017 at 10:18 AM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> I have changed as per the comments. 0002 and 0003 are changed, 0001 is
> still the same.
2 days back my colleague Rafia, reported one issue (offlist) that
parallel bitmap node is not scaling as good as oth
i;
For each clause we are processing all the buckets, can't we use some
data structure which can make multi-dimensions information searching
faster.
Something like HTree, RTree, Maybe storing histogram in these formats
will be difficult?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprise
t;>pgstat_track_sql is true, seems it's redundant here.
>
> Removed the check in pgstat_count_sqlstmt statement and add it
> exec_execute_message
> function where the check is missed.
>
> Updated patch attached.
Overall patch looks fine to me and marking it "ready f
nd the same
> pointer is stored in the tb structure. And in free function freeing that
> memory may cause problem.
>
> So either explicitly mentioning that the input must a palloc'ed data or
> by default allocate memory and copy the input data into allocated
> memory.
I have changed
On Thu, Jan 19, 2017 at 12:26 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> Patch 0001 and 0003 required to rebase on the latest head. 0002 is
>> still the same.
>
> I've committed the first half of 0001.
Thanks. 0001 and 0003 required rebasing after this commit.
On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> During debugging I found that subplan created for below part of the
> query is parallel_unsafe, Is it a problem or there is some explanation
> of why it's not parallel_safe,
Okay, so basically we
t1 WHERE a < 100
)
SELECT sum(n) FROM t);
--
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 13, 2017 at 6:36 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>
> Please verify with the new patch.
Patch 0001 and 0003 required to rebase on the latest head. 0002 is
still the same.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0001-opt-
On Wed, Jan 11, 2017 at 10:55 AM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> I have reviewed the latest patch and I don't have any more comments.
> So if there is no objection from other reviewers I can move it to
> "Ready For Committer"?
Seeing no objections,
On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> +void
> +pgstat_count_sqlstmt(const char *commandTag)
> +{
> + PgStat_SqlstmtEntry *htabent;
> + bool found;
> +
> + if (!pgstat_track_sql)
> + return
>
> Callers of pgst
did not find '}' at end of input node at character 762
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
select
subq_2.c1 as c0,
25 as c1
from
(select
pg_catalog.random() as c0,
31 as c1,
ref_3.
On Thu, Jan 12, 2017 at 5:47 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>> Hello Dilip,
>> I was trying to test the performance of all the parallel query related
>> patches on TPC-H queries, I found that when parallel hash [1 ]and your
>> patch are applied then Q1
nd Q14 were hanged, however, without any
> one of these patches, these queries are running fine. Following is the
> stack trace,
Thanks for reporting, I will look into this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
ah, the reason is to avoid unnecessary recursion. Also, in all
> other places in the code, we do handle both of them separately, refer
> cost_qual_eval_walker for somewhat similar usage.
ok.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers maili
_sqlstmt are always ensuring that
pgstat_track_sql is true, seems it's redundant here.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
28167 28057
64 26655 28712
128 20152 24917
256 16740 22891
Sync_Commit_On:
Client Head Patch
8 5102 5110
16 8087 8282
32 12523 12548
64 14701 15112
128 14656 15238
256 13421 164
;=
'1995-01-01'::date) AND (lineitem.l_shipdate <= '1996-03-31'::date))
Planning time: 2.742 ms
Execution time: 15509.696 ms
(21 rows)
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0001-opt-parallelcost-refactoring-v9.patch
Description: Binary data
0002-hash-support-
ernativeSubPlan here unless there is some strong reason?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
0002. I have also
observed another issue related to code refactoring, Actually, there
was some code present in 0001 which supposed to be in 0003.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0001-opt-parallelcost-refactoring-v8.patch
Description: Binary data
0002-hash-s
ong with my patch?
Did you properly clean the code?
I have asked one of my colleague to verify this and the result is
same, No crash.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re my suggested changes in the algorithm comments :
>
> @@ -103,27 +103,27 @@ BitmapHeapNext(BitmapHeapScanState *node)
Changed.
Apart from these changes, I have created a separate
patch(0001-opt-parallelcost-refactoring-v7.patch) for code refactoring
in optimizer required for parallelbitmap hea
> + extra);
> +
> + /* Generate partial path if inner is parallel safe. */
> + else if (inner_cheapest_total->parallel_safe)
> + try_partial_mergejoin_path(root,
> + joinrel,
> + outerpath,
> + inner_cheapest_total,
> + merge_pathkeys,
> + mergeclauses,
> + NIL,
> + innersortkeys,
> + jointype,
> + extra);
>
> In above code indentation is broken, similarly, there is another code
> in a patch where it is broken, try using pgindent.
Fixed with pgindent.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
parallel_mergejoin_v4.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
we no longer needed UNDO
for the heap page (e.g because of rollback) then we can apply the UNDO
and remove it. I agree that there will be multiple index entries will
be pointing to this tuple, but only one of them can pass the key
revalidation with the heap. isn't it?
--
Regards,
Dilip
746 rows=100 loops=1)
Planning time: 0.308 ms
Execution time: 1001.889 ms
In above example,
Without MVStat-> estimated: 10 Actual: 186607
With MVStat-> estimated: 163046 Actual: 186607
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hacke
On Mon, Dec 26, 2016 at 3:14 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> Other the another option is, that we can always make caller to provide
> an allocator. But this way every new user for simple hash need to take
> care of having allocator.
>
> What is your opinion?
hould be easily reproducible, in case it's not I can send
call stack or core dump.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
any call to PGSemaphoreUnlock. Am I missing something?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to make parallel plans
> more likely.
You can also try with reducing random_page_cost (that will help
parallel merge join with index scan), in case your data fits in memory
and you are ensuring warm cache environment.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Se
st
> using an allocator in shared memory does *NOT* allow the hash table to be
> used in shared memory in the general case.
Make sense.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
y OK to me
> on a first read-through.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
parallel_mergejoin_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Rebased on the current head.
On Tue, Dec 13, 2016 at 12:06 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> On Sat, Dec 10, 2016 at 5:36 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> Few assorted comments:
>
> Thanks for the review
>
>>
>> 1.
On Tue, Dec 13, 2016 at 8:34 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> I have created two patches as per the suggestion.
>
> 1. mergejoin_refactoring_v2.patch --> Move functionality of
> considering various merge join path into new function.
> 2. parallel_mergejo
On Tue, Dec 13, 2016 at 6:42 AM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>> This patch is hard to read because it is reorganizing a bunch of code
>> as well as adding new functionality. Perhaps you could separate it
>> into two patches, one with the refact
e places in above line. It should be
> written as below:
>
> dsa_entry = (void *)(((char *) dsa_entry) + sizeof(dsa_pointer));
Fixed..
>
> Similar stuff needs to be taken care at other places in the patch as
> well. I think it will be better if you run pgindent on your patch.
I
ting various merge join path) to new function called
generate_mergejoin_path. And, use it for normal outer path as well as
for partial outer path.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
bhYf%2B1gumpvW5bo_fpeNUy%2BrL-kg%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n value of this patch is that we can parallelize multi level join
query, where parallelism is not used becuase of merge join at some
level.
[1]
https://www.postgresql.org/message-id/CAA4eK1KA4LwTYXZG%3Dk3J2bA%2BZOEYnz2gkyWBKgY%3D_q0xJRBMDw%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB
n analyze output with patch (median of 3 runs)
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
20_head.out
Description: Binary data
20_patch.out
Description: Binary data
parallel_mergejoin_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hack
ted as a scankey, that'd be
> easy.
Isn't it better to directly make two separate lists during planning
itself, one for regular qual and other which can be converted to
scankey. Instead of keeping the flag in OpExpr ?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent
On Tue, Nov 29, 2016 at 11:21 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Nov 28, 2016 at 11:17 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>> Actually we want to call slot_getattr instead heap_getattr, because of
>> problem mentioned by Andres upthr
On Fri, Nov 25, 2016 at 6:55 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> I have changed the design to directly make it based on DSA instead of using
> DHT.
> In new version we no longer use DHT. Instead, of that I have made some
> change in simplehash[1], so that it
placed by an actual new structure definition.
>
Okay.
> - get_scankey_from_qual()'s prohibition on variable-width columns is
> presumably no longer necessary with this approach, right?
Correct.
>
> - Anything tested in SeqNext() will also need to be retested in
> SeqRecheck()
101 - 200 of 400 matches
Mail list logo
