On Sat, Feb 25, 2017 at 9:47 PM, Dilip Kumar wrote:
> On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila wrote:
>> Sure, but that should only happen if the function is *not* declared as
>> parallel safe (aka in parallel safe functions, we should not generate
>> parallel plans)
On Sat, Feb 25, 2017 at 3:22 PM, Dilip Kumar wrote:
> On Sat, Feb 25, 2017 at 11:29 AM, Amit Kapila wrote:
>> It seems you have forgotten to change in the below check:
>>
>> + if (innerpath != NULL &&
>> + innerpath->parallel_safe &
On Fri, Feb 24, 2017 at 11:30 AM, Dilip Kumar wrote:
> On Fri, Feb 24, 2017 at 10:06 AM, Amit Kapila wrote:
>> We have a below check in standard_planner() (!IsParallelWorker())
>> which should prohibit generating parallel plan inside worker, if that
>> is what you are seein
On Fri, Feb 24, 2017 at 4:49 PM, Dilip Kumar wrote:
> On Fri, Feb 24, 2017 at 3:04 PM, Amit Kapila wrote:
>> What advantage do you see for considering such a path when the cost of
>> innerpath is more than cheapest_total_inner? Remember the more paths
>> we try to consi
ou and Simon mean "recyclable" pages.
>
Yes, I think so and I think that is just confusion about terminology.
--
With Regards,
Amit Kapila.
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, Feb 24, 2017 at 3:42 PM, Dilip Kumar wrote:
> On Fri, Feb 24, 2017 at 3:04 PM, Amit Kapila wrote:
>
> Thanks for the comments.
>
>> What advantage do you see for considering such a path when the cost of
>> innerpath is more than cheapest_total_inner? Remember the
On Tue, Feb 14, 2017 at 5:22 PM, Dilip Kumar wrote:
> On Tue, Feb 14, 2017 at 12:25 PM, Amit Kapila wrote:
> Apart from this, there was one small problem in an earlier version
> which I have corrected in this.
>
> + /* Consider only parallel safe inner path */
> + if
base state.
>
+1. I also think you are right that there should not be a problem in
such a case.
--
With Regards,
Amit Kapila.
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
mp;
!IsolationIsSerializable())
{
/* all the cheap tests pass, so scan the query tree */
glob->maxParallelHazard = max_parallel_hazard(parse);
glob->parallelModeOK = (glob->maxParallelHazard != PROPARALLEL_UNSAFE);
}
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprised
On Thu, Feb 23, 2017 at 5:15 PM, Masahiko Sawada wrote:
> On Wed, Feb 22, 2017 at 12:01 AM, Amit Kapila wrote:
>
>> I understand that there could be some delay in reclaiming dead pages
>> but do you think it is such a big deal that we completely scan the
>> index for s
On Tue, Feb 21, 2017 at 1:09 AM, Simon Riggs wrote:
> On 20 February 2017 at 10:27, Amit Kapila wrote:
>> On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs wrote:
>>> On 20 February 2017 at 09:15, Amit Kapila wrote:
>>>> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Saw
we can decide how much percentage of
buckets are allocated in current table half? I think we might be able
to construct this information after crash recovery as well.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs wrote:
> On 20 February 2017 at 09:15, Amit Kapila wrote:
>> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada
>> wrote:
>>> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote:
>>>> On Thu, Feb 16, 2017 at 6:17
ke it any
faster than just adding Materialize on top of Gather Merge. So, it
seems better not to go there unless we see some use of it.
--
With Regards,
Amit Kapila.
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
omeway
that there are many such pages. Also, I think we do reclaim the
complete page while allocating a new page in btree.
> The half-dead pages are never cleaned up if the ratio of pages
> containing garbage is always lower than threshold.
>
Which threshold are you referring here?
--
With Regards,
Amit Kapila.
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 Sun, Feb 19, 2017 at 8:32 PM, Robert Haas wrote:
> On Sun, Feb 19, 2017 at 6:50 PM, Amit Kapila wrote:
>> To close the remaining gap, don't you think we can check slot->in_use
>> flag when generation number for handle and slot are same.
>
> That doesn't
lel Seq Scan, we do wait for parallel workers to finish
before freeing the shared memory. Why the case is different here?
--
With Regards,
Amit Kapila.
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 Sun, Feb 19, 2017 at 2:22 PM, Robert Haas wrote:
> On Sat, Feb 18, 2017 at 6:43 PM, Amit Kapila wrote:
>> I think there is a value in supporting mark/restore position for any
>> node which produces sorted results, however, if you don't want to
>> support it, the
the starting process, that closes
> this hole. Almost.
>
To close the remaining gap, don't you think we can check slot->in_use
flag when generation number for handle and slot are same.
--
With Regards,
Amit Kapila.
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, Feb 17, 2017 at 6:27 PM, Rushabh Lathia
wrote:
> On Fri, Feb 17, 2017 at 4:47 PM, Amit Kapila
> wrote:
>>
>> Are you suggesting that commit 0c2070ce has helped to improve
>> performance if so, I don't think that has been proved? I guess the
>>
On Fri, Feb 17, 2017 at 10:35 AM, Rafia Sabih
wrote:
>
>
> On Thu, Feb 16, 2017 at 9:25 PM, Amit Kapila
> wrote:
>>
>>
>> 4.
>> ExecReScanIndexOnlyScan(IndexOnlyScanState *node)
>> {
>> ..
>> + /*
>> + * if we are here to just
On Fri, Feb 17, 2017 at 9:15 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Fri, Feb 17, 2017 at 11:22 AM, Tom Lane wrote:
>>> In short, it looks to me like ExecShutdownGatherWorkers doesn't actually
>>> wait for parallel workers to finish (as its comment sugges
red, thousand from tenk2 where thousand > 100);
> 2017-02-17 00:28:33.254 EST [18934] LOG: LaunchParallelWorkers: failed to
> register 3 of 4 workers
> 2017-02-17 00:28:33.254 EST [18934] STATEMENT: select count(*) from tenk1
> where (two, four) not in
> (select hundred, thousand from tenk2 where thousand > 100);
Now, I think that the test added by commit 5e6d8d2 doesn't have a
problem because it is normally okay to run parallel query tests even
when required workers are not available. I think what we need to do
here is to move the test that needs workers to execute before other
parallel query tests where there is no such requirement.
--
With Regards,
Amit Kapila.
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
eated;
It has added both explain statement test and a test to exercise
parallel index scan code.
--
With Regards,
Amit Kapila.
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, Feb 16, 2017 at 8:16 PM, Amit Kapila wrote:
> On Thu, Feb 16, 2017 at 7:15 AM, Robert Haas wrote:
>
> Attached are refactoring patches. WAL patch needs some changes based
> on above comments, so will post it later.
>
Attached is a rebased patch to enable WAL logging f
;t reset parallel
+ * scan
+ */
+ if (node->ioss_NumRuntimeKeys != 0 && !node->ioss_RuntimeKeysReady)
+ reset_parallel_scan = false;
..
}
I think here you can update the comment to indicate that for detailed
reason refer ExecReScanIndexScan.
--
With Regards,
Amit Kapila.
Enterpr
On Thu, Feb 16, 2017 at 7:15 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 10:22 AM, Amit Kapila wrote:
>> As discussed, attached are refactoring patches and a patch to enable
>> WAL for the hash index on top of them.
>
> Thanks. I think that the refactoring
ely limited so I don't know
> how much help I can be, but we'd like to see this resolved beyond the quick
> fix, or at least understand why it happened.
>
Thanks Justin for the confirmation. Is it possible for you to get a
standalone test case with which we can reproduce the pro
On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
>> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
>> wrote:>
>>> support related patch. In anycase, to avoid confusion I am attaching
>>> al
On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji wrote:
> Amit Kapila wrote:
>> How will you decide just based on oldest xmin whether the tuple is visible
>> or not? How will you take decisions about tuples which have xmax set?
>
> In our use case, GetOldestXmin is used by a
the second patch.
>
I have rebased the optimizer/executor support related patch.
[1] -
https://www.postgresql.org/message-id/CAA4eK1%2BTnM4pXQbvn7OXqam%2Bk_HZqb0ROZUMxOiL6DWJYCyYow%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
parallel_index_scan_v10.patch
Descript
On Wed, Feb 15, 2017 at 4:38 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 4:24 AM, Amit Kapila wrote:
>> On further evaluation, it seems this patch has one big problem which
>> is that it will allow forming parallel plans which can't be supported
>> with curre
On Wed, Feb 15, 2017 at 4:46 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 11:07 PM, Amit Kapila wrote:
>> I have removed the check of AlternativeSubPlan so that it can be
>> handled by expression_tree_walker.
> ...
>> Attached patch fixes all the comments raised till
and they seem to be better than what is there in the
patch.
[1] -
https://www.postgresql.org/message-id/3863bca17face15c6acd507e0173a6dc%40xs4all.nl
--
With Regards,
Amit Kapila.
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
ether the tuple is
visible or not? How will you take decisions about tuples which have
xmax set?
--
With Regards,
Amit Kapila.
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 Tue, Jan 3, 2017 at 4:19 PM, Amit Kapila wrote:
> On Wed, Dec 28, 2016 at 11:47 AM, Amit Kapila wrote:
>>
>> Now, we can further extend this to parallelize queries containing
>> correlated subplans like below:
>>
>> explain select * from t1 where t1.i in (se
he aggregation accordingly.
This part of the sentence sounds unclear. It doesn't clearly
indicate that planner won't choose a parallel plan in such cases.
--
With Regards,
Amit Kapila.
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 Wed, Jan 4, 2017 at 9:27 PM, Dilip Kumar wrote:
> On Wed, Jan 4, 2017 at 12:02 PM, Amit Kapila wrote:
>> 3.
>> + /*
>> + * See comments in try_partial_nestloop_path().
>> + */
>>
>> This same code exists in try_partial_nestloop_path() and
>> try_
On Thu, Feb 2, 2017 at 9:23 AM, Amit Kapila wrote:
> On Wed, Feb 1, 2017 at 10:04 PM, Robert Haas wrote:
>> On Tue, Jan 31, 2017 at 6:01 AM, Amit Kapila wrote:
>>> Moved this patch to next CF.
>>
>> So here is what seems to be the key hunk from this patch:
>
On Mon, Feb 13, 2017 at 5:47 PM, Robert Haas wrote:
> On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote:
>>>>> Why can't we rely on _bt_walk_left?
>>>> The reason is mentioned in comments, but let me try to explain with
>>>> some example. When you
hat happen under any circumstances. I find all this highly
> confusing. Have I missed some further subtlety that applies with
> PARALLEL RESTRICTED?
>
The basic idea of parallel restricted is that any expression will be
considered parallel restricted if that can't be executed in the
worker,
On Fri, Feb 10, 2017 at 11:27 PM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote:
>>> The hunk in indexam.c looks like a leftover that can be omitted.
>>
>> It is not a leftover hunk. Earlier, the patch has the same check
>> btparallelrescan
On Sat, Feb 11, 2017 at 9:41 PM, Robert Haas wrote:
> On Fri, Feb 10, 2017 at 11:22 PM, Amit Kapila wrote:
>>> Why can't we rely on _bt_walk_left?
>>
>> The reason is mentioned in comments, but let me try to explain with
>> some example. When you reach that
On Fri, Feb 10, 2017 at 11:27 PM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote:
>>> The hunk in indexam.c looks like a leftover that can be omitted.
>>
>> It is not a leftover hunk. Earlier, the patch has the same check
>> btparallelrescan
hts?
>
Yes, I also don't see any need of defining it in parallel.c. I think
she has kept to report it in pg_stat_activity, but I feel that code
can also be moved to execParallel.c.
Another question is don't we need to set debug_query_string in worker?
--
With Regards,
Amit Kapila.
thing, but if someone can present a use case, then I think we can
try to support such parallel plans.
--
With Regards,
Amit Kapila.
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 Tue, Jan 31, 2017 at 4:16 PM, Amit Kapila wrote:
> On Wed, Dec 28, 2016 at 5:20 PM, Amit Kapila wrote:
>
>> The drawback of the second approach is
>> that we need to evaluate the initplan before it is actually required
>> which means that we might evaluate it even
and target_session_attrs are
> both new in v10 and have non-empty default values, yet neither of them
> seems like something that you necessarily want in your
> automatically-created recovery.conf file. It seems like it would be
> more correct to leave out parameters that are set to the defa
d. The way to extend it could be that
while dumping it just dumps the btree internal pages or something like
that.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Thu, Feb 9, 2017 at 12:08 PM, Peter Geoghegan wrote:
> On Wed, Feb 8, 2017 at 10:33 PM, Amit Kapila wrote:
>> I had some offlist discussion with Robert about the above point and we
>> feel that keeping only heap pages for parallel computation might not
>> be future proof
On Sat, Feb 4, 2017 at 7:14 AM, Amit Kapila wrote:
> On Sat, Feb 4, 2017 at 5:54 AM, Robert Haas wrote:
>> On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote:
>
>> On balance, I'm somewhat inclined to think that we ought to base
>> everything on heap pages, so that
set?
I think there should be a separate column for write and sync time.
> Or it is possible to integrate the new columns into the existing
> pg_stat_bgwriter view also.
>
I feel separate view is better.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via
On Tue, Feb 7, 2017 at 5:14 PM, Mithun Cy wrote:
> On Tue, Feb 7, 2017 at 12:24 PM, Amit Kapila wrote:
>> On Tue, Feb 7, 2017 at 11:53 AM, Beena Emerson
>> wrote:
>>> Are 2 workers required?
>>>
>>
>> I think in the new design there is a provision o
hat we are discussing in thread:
https://www.postgresql.org/message-id/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
MAX_INVALID;
>
> Comment doesn't address this logic. Also, the "else" case shouldn't
> exist at all, I think.
>
In the *if* check, it just checks frozen status of xmin, so I think
you need to mask xmax related bits in else check. Can you explain
what makes you think that
ping a
> lock-file before starting the bgworkers. But, if there is an another
> method to avoid launching bgworker on a simple method I can do same.
>
How about keeping a variable in PROC_HDR structure to indicate if
already one dump worker is running, then don't allow to start a
needs a
pair of workers. Also, if the dump interval is greater than zero,
then do we really need to separately register a dynamic worker?
--
With Regards,
Amit Kapila.
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
here onwards.
>
> Maybe we should call them "unused pages".
>
+1. If we consider some more names for that column then probably one
alternative could be "empty pages".
--
With Regards,
Amit Kapila.
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 Mon, Feb 6, 2017 at 10:28 PM, Tom Lane wrote:
> Amit Kapila writes:
>> Hmm. Consider that the first time relcahe invalidation occurs while
>> computing id_attrs, so now the retry logic will compute the correct
>> set of attrs (considering two indexes, if we take
tine 'XLogReadBufferExtended' does not expect a page to be
> completely zero page else it returns Invalid Buffer. To fix this, we
> started initializing freed overflow page and newly allocated bucket
> pages using _hash_pageinit() hence I don't think there will be any
> ze
On Mon, Feb 6, 2017 at 9:47 AM, Pavan Deolasee wrote:
>
>
> On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila wrote:
>>
>>
>>
>> Hmm. Consider that the first time relcahe invalidation occurs while
>> computing id_attrs, so now the retry logic will compute the c
On Mon, Feb 6, 2017 at 8:35 AM, Pavan Deolasee wrote:
>
>
> On Mon, Feb 6, 2017 at 8:15 AM, Amit Kapila wrote:
>>
>> On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee
>> wrote:
>> >
>> >
>> > On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote
dex set changes, which
> fits in the situation we're dealing with.
>
Don't you think it also has the same problem as mentioned by me in
Alvaro's patch and you also agreed on it? Do you see any need to fix
it locally in
RelationGetIndexAttrBitmap(), why can't we clear at
p for
next time is on spot. I am not sure but I think your solution can be
extended to make it somewhat similar to what we do with rd_indexvalid
(basically, we should set rd_bitmapsvalid to 2 (bitmap is temporarily
forced) at rel cache invalidation and then clean it up transaction
end). I can try something on those lines.
--
With Regards,
Amit Kapila.
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
rther-back branches. I'll sort that out when I split
> things up. Right now the question is whether individual items are
> correctly/adequately documented.
>
> Fix possible miss of socket read events while waiting on Windows (Amit Kapial)
Typo
Amit Kapial/Amit Kapila
--
With
eap_update()
{
..
* Note that we get a copy here, so we need not worry about relcache flush
* happening midway through.
*/
hot_attrs = RelationGetIndexAttrBitmap(relation, INDEX_ATTR_BITMAP_ALL);
key_attrs = RelationGetIndexAttrBitmap(relation, INDEX_ATTR_BITMAP_KEY);
id_attrs = RelationGetIndexAttrBitmap(
On Sat, Feb 4, 2017 at 4:37 AM, Jeff Janes wrote:
> On Thu, Jan 12, 2017 at 7:23 PM, Amit Kapila
> wrote:
>>
>> On Fri, Jan 13, 2017 at 1:04 AM, Jesper Pedersen
>> wrote:
>> > On 12/27/2016 01:58 AM, Amit Kapila wrote:
>> >>
>> >> After r
On Sat, Feb 4, 2017 at 5:54 AM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote:
>> Yeah, I understand that point and I can see there is strong argument
>> to do that way, but let's wait and see what others including Robert
>> have to say about t
problem for me (I've only
> tried master), but I am not sure if this is a correct fix.
>
I think it is difficult to say that fix is correct unless there is a
clear explanation of what led to this problem. Another angle to
investigate is to find out when relation->rd_indexvalid is set
uot; or "Rejected" or "Moved to next CF". OTOH,
there is some value in sending a separate mail for each patch so that
people can argue on the decision by CFM for one particular patch, but
not sure if it worth.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterpr
On Wed, Feb 1, 2017 at 10:04 PM, Robert Haas wrote:
> On Tue, Jan 31, 2017 at 6:01 AM, Amit Kapila wrote:
>> Moved this patch to next CF.
>
> So here is what seems to be the key hunk from this patch:
>
> /*
> - * Since we don't have the ability to pus
On Wed, Feb 1, 2017 at 3:52 AM, Robert Haas wrote:
> On Tue, Jan 24, 2017 at 4:51 PM, Robert Haas wrote:
>> On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
>>> In spite of being careful, I missed reorganizing the functions in
>>> genam.h which I have done in
ages scanned.
>
Yeah, I understand that point and I can see there is strong argument
to do that way, but let's wait and see what others including Robert
have to say about this point.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing l
On Tue, Jan 24, 2017 at 10:59 AM, Amit Kapila wrote:
> On Thu, Jan 19, 2017 at 4:51 PM, Dilip Kumar wrote:
>> On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar wrote:
>>> During debugging I found that subplan created for below part of the
>>> query is parallel_unsafe,
On Wed, Dec 28, 2016 at 5:20 PM, Amit Kapila wrote:
> To start
> with let us see the plan of TPC-H query (Q-22) and understand how it
> can be improved.
>
> Limit
>InitPlan 1 (returns $0)
> -> Finalize Aggregate
>-> Gather
>
On Mon, Jan 30, 2017 at 7:16 AM, Tsunakawa, Takayuki
wrote:
> From: Amit Kapila [mailto:amit.kapil...@gmail.com]
>> Hmm. It doesn't work even on a command prompt with administrative
>> privileges. It gives below error:
>>
>> waiting for server to start2017-01-
On Sat, Jan 28, 2017 at 1:34 AM, Robert Haas wrote:
> On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
>> parallel_index_opt_exec_support_v6 - Removed the usage of
>> GatherSupportsBackwardScan. Expanded the comments in
>> ExecReScanIndexScan.
>
> I looked thr
to do so there is high chance of getting deadlock which i assume is
> expected behaviour in database.
>
I agree with your analysis, surely trying to update multiple rows with
same values from different backends can lead to deadlock.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://w
t; In my experience, that kind of use is just as interesting as preserving
> the buffers across a restart.
>
An interesting use case. I am not sure if somebody has tried that way
but it appears to me that the current proposed patch should work for
this use case.
--
With Regards,
Ami
e that the test case
is such that the deadlock is expected in rare cases, if that is the
case then it is okay. I have not spent enough time on that to comment
whether it is a test or code issue.
[1] -
https://www.postgresql.org/message-id/dc6d7247-050f-4014-8c80-a4ee676eb384%40redhat.com
--
Wi
On Fri, Jan 27, 2017 at 6:53 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Jan 23, 2017 at 5:07 PM, Amit Kapila
> wrote:
>>
>> On Fri, Jan 20, 2017 at 7:29 AM, Haribabu Kommi
>> wrote:
>> > I didn't find any better names other than the fol
cing the patch.
1.
+TO DO:
+--
+Add functionality to dump based on timer at regular interval.
I think you need to remove above TO DO.
2.
+ /* Load the page only if there exist a free buffer. We do not want to
+ * replace an existing buffer. */
This is not a PG style multiline comment.
--
On Tue, Jan 24, 2017 at 10:59 AM, Amit Kapila wrote:
> On Thu, Jan 19, 2017 at 4:51 PM, Dilip Kumar wrote:
>> On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar wrote:
>>> During debugging I found that subplan created for below part of the
>>> query is parallel_unsafe,
On Wed, Jan 18, 2017 at 11:51 AM, Mithun Cy wrote:
> On Tue, Jan 17, 2017 at 10:07 AM, Amit Kapila wrote:
>
>> (b) Another somewhat bigger problem is that with this new change it
>> won't retain the pin on meta page till the end which means we might
>> need t
p the interface as proposed by
you. TBH, I am not sure how important is to expose this
(hash_bitmap_info()) function, but let's keep it and see if committer
has any opinion on this API.
--
With Regards,
Amit Kapila.
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
ntial for this project).
So, I have set parallel_safe as false for CTE subplans.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
pq_pushdown_subplan_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
On Mon, Jan 23, 2017 at 6:57 PM, Tomas Vondra
wrote:
> On 01/23/2017 01:40 PM, Amit Kapila wrote:
>>
>> On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra
>> wrote:
>>>
>>> On 01/23/2017 09:57 AM, Amit Kapila wrote:
>>>>
>>>>
On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra
wrote:
> On 01/23/2017 09:57 AM, Amit Kapila wrote:
>>
>> On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
>> wrote:
>>>
>>> On 01/23/2017 08:30 AM, Amit Kapila wrote:
>>>>
>>>>
>>&g
to determine the overflow bit number which can be
> used further to identify the bitmap page.
>
I think you can get that from bucket number by using BUCKET_TO_BLKNO.
You can get bucket number from page's opaque data. So, if we follow
that then you can have a prototype of a function as
h
1a70450b5e7084991b9caa15cb58a2820df
>> Author: Andres Freund
>> Date: Thu Dec 25 18:24:20 2014 +0100
>>
>> Lockless StrategyGetBuffer clock sweep hot path.
>
> Looks good to me.
>
+1.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
-
On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
wrote:
> On 01/23/2017 08:30 AM, Amit Kapila wrote:
>>
>>
>> I think if we can get data for pgbench read-write workload when data
>> doesn't fit in shared buffers but fit in RAM, that can give us some
>> indicatio
also makes sense to check the
WAL data size for each of those runs.
--
With Regards,
Amit Kapila.
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 20, 2017 at 7:29 AM, Haribabu Kommi
wrote:
>
> On Thu, Jan 19, 2017 at 1:18 AM, Amit Kapila
> wrote:
>> >
>> > +extern BlockNumber _bt_parallel_seize(IndexScanDesc scan, bool
>> > *status);
>> > +extern void _bt_parallel_release(I
On Sat, Jan 21, 2017 at 12:23 PM, Amit Kapila wrote:
> On Sat, Jan 21, 2017 at 1:15 AM, Robert Haas wrote:
>>
>> I think it's a good idea to put all three of those functions together
>> in the listing, similar to what we did in
>> 69d34408e5e7adcef8ef2f4e9c4f2
g the INSERTs as a reason to VACUUM is also very natural when you
> consider the need to update BRIN indexes.
>
Another possible advantage of tracking INSERTs is for hash indexes
where after split we need to remove tuples from buckets that underwent
split recently.
--
With Regards,
Amit Kapila.
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 Sat, Jan 21, 2017 at 1:15 AM, Robert Haas wrote:
> On Fri, Jan 20, 2017 at 9:29 AM, Amit Kapila wrote:
>> Sure, if scan keys have changed then we can't continue, but this is
>> the case where runtime keys are first time initialized.
>>
>> if (node-&
On Fri, Jan 20, 2017 at 3:41 AM, Robert Haas wrote:
> On Wed, Jan 18, 2017 at 8:03 AM, Amit Kapila wrote:
>>> Why do we need separate AM support for index_parallelrescan()? Why
>>> can't index_rescan() cover that case?
>>
>> The reason is that sometime
On Fri, Jan 20, 2017 at 12:59 AM, Robert Haas wrote:
> On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila wrote:
>> Fixed.
>
>
> If all of that were no issue, the considerations in
> TargetListSupportsBackwardScan could be a problem, too. But I think
> there shouldn't be
On Thu, Jan 19, 2017 at 12:28 AM, Robert Haas wrote:
> On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
>> Fixed.
>
> With respect to the second patch
> (parallel_index_opt_exec_support_v4.patch), I'm hoping it can use the
> new function from Dilip's bitmap h
On Wed, Jan 18, 2017 at 6:25 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila
> wrote:
>>
>>
>> Changed as per suggestion.
>>
>>
>> I have also rebased the optimizer/executor support patch
>> (parallel_index_opt
501 - 600 of 3368 matches
Mail list logo
