'1996-03-31'::date))
> Planning time: 0.207 ms
> Execution time: 6669.195 ms
> (13 rows)
>
>
> Summary:
> -> With patch overall execution is 2 time faster compared to head.
> -> Bitmap creation with patch is bit slower compared to head and thats
> because of DHT
yes, do we want to
retain this code in its current form under define UNUSED, is there any
advantage of same. Another point is that won't this commit make
information in xl_btree_vacuum redundant, so shouldn't we remove it
usage during WAL writing as well?
--
With Regards,
Amit Kapila.
EnterpriseDB:
On Thu, Oct 20, 2016 at 7:39 AM, Peter Geoghegan <p...@heroku.com> wrote:
> On Mon, Oct 17, 2016 at 8:08 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> Create Index With (parallel_workers = 4);
>>
>> If above syntax looks sensible, then we might nee
On Wed, Oct 19, 2016 at 5:57 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Oct 18, 2016 at 10:52 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> On Wed, Oct 5, 201
On Tue, Oct 18, 2016 at 10:52 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Tue, Oct 4, 2016
based on number of pages
>>to be fetched/scanned from index.
> IIUC, its not possible to know the exact number of pages scanned from an
> index
> in advance.
We can't find the exact numbers of index pages to be scanned, but I
think we can find estimated number of pages to be fetched (ref
On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 12:36 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> I think one way to avoid the risk of deadlock in above scenario is to
>> take the cleanup lock conditionally,
On Thu, Oct 13, 2016 at 8:48 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> As of now, the driving table for parallel query is accessed by
> parallel sequential scan which limits its usage to a certain degree.
> Parallelising index scans would further increase the usage of p
ke you have devised
a new way for leader to know when workers have finished which might be
required for this patch. However, have you tried to use or
investigate if existing infrastructure which serves same purpose could
be used for 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
f tuple into tuple array.
>
Won't extra copy per tuple impact performance? Is the fix in
mentioned commit was for record or composite types, if so, does
GatherMerge support such types and if it support, does it provide any
benefit over Gather?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.ent
arallelFinish()->ExecParallelRetrieveInstrumentation(), so I am
wondering why can't you collect the additional information in the same
way?
--
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
nk it is possible with ~100,000 tps.
>
> There's certainly much more interesting stuff in the results, but I
> don't have time for more thorough analysis now - I only intended to do
> some "quick benchmarking" on the patch, and I've already spent days on
> this, and I have other things to do.
>
Thanks a ton for doing such a detailed testing.
[1] -
https://www.postgresql.org/message-id/CA%2BTgmoahCx6XgprR%3Dp5%3D%3DcF0g9uhSHsJxVdWdUEHN9H2Mv0gkw%40mail.gmail.com
[2] -
https://www.postgresql.org/message-id/CAA4eK1%2BSoW3FBrdZV%2B3m34uCByK3DMPy_9QQs34yvN8spByzyA%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 subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
3 where I read test table again after
> enough time. But I could never get "snapshot too old" error at #3.
>
Here, the basic idea is that till the time corresponding page is not
pruned or table vacuuming hasn't triggered, this error won't occur.
So, I think what is happening here that
On Fri, Oct 14, 2016 at 2:52 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Oct 13, 2016 at 6:33 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> If we agree that above is a problematic case, then some of the options
>> to solve it could be (a) Vacuum sh
On Fri, Oct 14, 2016 at 3:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Thu, Oct 13, 2016 at 6:33 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> If we agree that above is a problematic case, then some
scans.
Thoughts?
[1] -
https://www.postgresql.org/message-id/CAA4eK1%2BJM%2BffHgUfW8wf%2BLgn2eJ1fGjyn6b_L5m0fiTEj2_6Pw%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
ve observed with Parallel Sequential Scans.
I think we can parallelise Index Only Scans as well, but I have not
evaluated the same and certainly it can be done as a separate patch in
future.
Contributions
----
First patch (parallel_index_scan_v1.patch) implements parallelism at
In
On Mon, Oct 10, 2016 at 10:07 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Mon, Oct 10, 2016 at 5:55 AM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>> On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila <amit.kapil...@gmail.com>
>> wrote:
>>
?
[1] - https://www.postgresql.org/message-id/15344.1473974558%40sss.pgh.pa.us
--
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, Oct 9, 2016 at 10:59 PM, Francisco Olarte
<fola...@peoplecall.com> wrote:
> On Sat, Oct 8, 2016 at 2:22 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> On Sat, Oct 8, 2016 at 9:12 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
>>>
On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
>> Another thing I don't quite understand about this algorithm is that in
>> order to conditionally lock
On Sat, Oct 8, 2016 at 5:52 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Sat, Oct 8, 2016 at 9:12 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Fri, Oct 7, 2016 at 10:16 PM, Alvaro Herrera
>> <alvhe...@2ndquadrant.com> wrote:
>>> R
ps://www.postgresql.org/message-id/CA%2BbJJbx8%2BSKBU%3DXUE%2BHxZHysh9226iMfTnA69AznwRTOEGtR7Q%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 subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unts (32) on 192 - Hyper Threaded m/c, the
performance is 20~30% better, but at higher client counts, it was same
as 100 fill factor. I think if go by your theory, one could also
argue to have non-default values autovacuum threshold parameters.
pgbench already has a parameter to specify non-defau
e doing
both writes and fsync under one lock. However, if we can split the
work such that writes are done under one lock and fsync under separate
lock, then probably we can try to buffer fsync requests and after
fsyncing the current pending requests, we can recheck if there are
more pendi
gt; I haven't done much more testing (e.g. with -N to eliminate
>>> collisions on branches) yet, let's see if it changes anything.
>>>
>>
>> Yeah, let us see how it behaves with -N. Also, I think we could try
>> at higher scale factor?
>>
>
> Yes, I plan to
On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 12:36 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> I think one way to avoid the risk of deadlock in above scenario is to
>> take the cleanup lock conditionally,
On Tue, Oct 4, 2016 at 7:50 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 9:20 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>>> I'd say that the reason for not using included columns in any
>>>> operations which require compa
nt-lock56182 62442 61234
> group-update 55019 61587 60485
>
Are the above results with synchronous_commit=off?
> I haven't done much more testing (e.g. with -N to eliminate collisions on
> branches) yet, let's see if it changes anything.
>
Yeah, let us
some of the mails in
this thread, it is because some of the other databases doesn't seem to
support ordering for included columns or supporting the same can
complicate the code. One point, we should keep in mind that
suggestion for including many other columns in INCLUDING clause to use
Index Only sca
On Tue, Oct 4, 2016 at 10:06 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Wed, Sep 28, 20
On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Wed, Sep 28, 2016 at 3:04 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>
>> As I was looking
I think hash indexes are theoretically
faster than btree and we have seen that practically as well for quite a few
cases (for read workloads - when used with unique data and also in nest
loops).
With Regards,
Amit Kapila
has a code
which can prove both theoretically and practically that it is better than
hash indexes for all usages.
Note - excuse me for formatting of this email as I am on travel and using
my phone.
With Regards,
Amit Kapila.
As per code, there is no such intention (loop over tuples). It is
about reading the page and getting the tuple.
> +step to next page if necessary (no chaining of locks)
> +if the scan indicates moved by split, then move to old bucket
> after the scan
> +of current bucket is finished
> get tuple
> release buffer content lock and pin on current page
> -- at scan shutdown:
> -release bucket share-lock
>
> Don't we have a pin to release at scan shutdown in the new system?
>
Yes, it is mentioned in line below:
+ release any pin we hold on current buffer, old bucket buffer, new
bucket buffer
+
> Well, I was hoping to get through the whole patch in one email, but
> I'm not even all the way through the README. However, it's late, so
> I'm stopping here for now.
>
Thanks for the review!
--
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
odel and it makes a difference (although that seems unlikely).
>
> I am using "Intel(R) Xeon(R) CPU E7- 8830 @ 2.13GHz "
>
Another difference is that m/c on which Dilip is doing tests has 8 sockets.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sen
XLogFlush to update
> minRecoveryPoint.
>
IIRC, there is already a patch to update the minRecoveryPoint
correctly, can you check if that solves the problem for you?
[1] -
https://www.postgresql.org/message-id/20160609.215558.118976703.horiguchi.kyotaro%40lab.ntt.co.jp
--
With Regards,
Amit Kapila.
On Mon, Sep 26, 2016 at 8:54 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Sun, Sep 25, 2016 at 9:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Amit Kapila <amit.kapil...@gmail.com> writes:
>>> On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane <t...@sss
On Sun, Sep 25, 2016 at 9:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> This is clearly an oversight in Simon's patch fafa374f2, which
On Sun, Sep 25, 2016 at 10:30 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Fri, Sep 23, 2016 at 5:34 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>
>> I think here I am slightly wrong. For the full page writes, it do use
>> RBM_ZERO_AND_LOCK mode t
hes to make it wal-enabled, more concurrent and
performant, page inspect module are available) for hash indexes and
still more is in progress, that sounds like a step backward then step
forward.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers m
On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Mon, Sep 19, 2016 at 7:07 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> I think you have a valid point. It seems we don't need
s fast as possible, thus avoiding
> some performance degradation.
>
Isn't it somewhat overlaps with existing parameter
checkpoint_completion_target? You can use
checkpoint_completion_target to throttle the checkpoints. The option
you are suggesting seems to be more straight forward
On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
> 20.09.2016 08:21, Amit Kapila:
>
> On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova
> <a.lubennik...@postgrespro.ru> wrote:
>
> 28.08.2016 09:13, Amit Kapila:
>
&g
on in code, but I think it is worth trying.
Won't it add some requirements for pg_upgrade as well?
--
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, Sep 23, 2016 at 8:22 PM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
> On 09/23/2016 03:07 PM, Amit Kapila wrote:
>>
>> On Fri, Sep 23, 2016 at 6:16 PM, Tomas Vondra
>> <tomas.von...@2ndquadrant.com> wrote:
>>>
>
On Fri, Sep 23, 2016 at 7:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> Now, it is quite possible
>> that error code is set to 0 on success in my windows environment
>> (Win7) and doesn't work in some other environ
on upthread [1]. It is clear that patch
has reduced LWLock contention from ~28% to ~4% (where the major
contributor was TransactionIdSetPageStatus which has reduced from ~53%
to ~3%). Isn't it inline with what you are looking for?
[1] -
https://www.postgresql.org/message-id/CAFiTN-u-XEzhd%3DhN
On Fri, Sep 23, 2016 at 6:29 PM, Pavan Deolasee
<pavan.deola...@gmail.com> wrote:
> On Fri, Sep 23, 2016 at 6:05 PM, Tomas Vondra <tomas.von...@2ndquadrant.com>
> wrote:
>>
>> On 09/23/2016 05:10 AM, Amit Kapila wrote:
>>>
>>> On Fri, Sep
-create the database
between each run, otherwise data bloat could impact the readings.
I think in general, the impact should be same for both the kernels
because you are using same parameters, but I think if use appropriate
parameters, then you can get consistent results for 3.2.80. I have
also seen
On Fri, Sep 23, 2016 at 6:11 PM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 9/23/16 1:56 AM, Amit Kapila wrote:
>> which comment are you referring here? hashm_mapp contains block
>> numbers of bitmap pages.
>
> The comment I'm referring
On Thu, Sep 22, 2016 at 10:16 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Sep 22, 2016 at 8:51 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>>
>>
>> Correct. But any torn page write must be covered by the restoration of a
>> f
On Thu, Sep 22, 2016 at 10:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> On Tue, Sep 20, 2016 at 10:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> ISTM both the previous coding and this version can fail
m(tv.tv_sec);
>> ...
>> dsm_control_handle = random();
>
> for the time being.
>
Isn't it better if we use the same technique in dsm_create() as well
which uses random() for handle?
--
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
o calculate
max_avail space for all pages in same way. Don't you need to
calculate it differently for bitmap page or meta page as they don't
share the same format as other type of 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
which we are waiting?
>
I also think that it can add some confusion in defining boundaries and
also might not be consistent with current way we have defined the
waits, however there is some value in using subsystem which is that
user can identify the bottlenecks with ease. I think
> Finally, extensions got their own category in this taxonomy, though I
> wonder if it would be better to instead have
> Activity/ExtensionActivity, Client/ExtensionClient,
> Timeout/ExtensionTimeout, and IPC/ExtensionIPC instead of making it a
> separate toplevel categ
On Thu, Sep 22, 2016 at 7:32 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> I think for certain cases like into clause, the rows passed will be
>> equal to actual number of rows, other
On Fri, Sep 23, 2016 at 5:14 AM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
> On 09/21/2016 08:04 AM, Amit Kapila wrote:
>>
>
> (c) Although it's not visible in the results, 4.5.5 almost perfectly
> eliminated the fluctuations in the results. For example when 3.2.80
t. But I agree with you
>> that there's certainly not enough evidence to commit any of these
>> patches now. To my mind, these numbers aren't convincing.
>>
>
> Yes, the chicken-and-egg problem is why the tests were done with unlogged
> tables (to work around the WAL lock)
On Tue, Sep 20, 2016 at 8:31 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> I think here point is that for any case where there is count of rows
>> to be selected, we disable paralleli
On Fri, Sep 16, 2016 at 9:56 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Fri, Sep 16, 2016 at 4:20 AM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>> Currently README of hash module contain algorithms written in below form.
>>
>> The insert
On Thu, Sep 22, 2016 at 8:51 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Tue, Sep 20, 2016 at 10:27 PM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>> On Tue, Sep 20, 2016 at 10:24 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>> >
want to say that don't assume that all people
involved in current development of hash indexes or further development
on it will run away once the code is committed and the responsibility
of maintenance will be on other senior members of community.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enter
tps://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx
[2] -
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680627(v=vs.85).aspx
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
gt; because of the very high client counts.
>
No issues, I have already explained why I think it is important to
reduce the remaining CLOGControlLock contention in yesterday's and
this mail. If none of you is convinced, then I think we have no
choice but to drop this patch.
--
With Regards
On Tue, Sep 20, 2016 at 10:24 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>>
>> Okay, Thanks for pointing out the same. I have fixed it. Apart from
>> that, I have c
On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> In general, I think we should support the cases as required (or
>> written) by you from plpgsql or sql fu
On Mon, Sep 19, 2016 at 8:44 PM, Mithun Cy <mithun...@enterprisedb.com> wrote:
> On Sat, Aug 6, 2016 at 9:41 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> I wonder why you have included a new file for these tests, why can't be
>> these added to exist
On Tue, Sep 20, 2016 at 10:51 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova
> <a.lubennik...@postgrespro.ru> wrote:
>> 28.08.2016 09:13, Amit Kapila:
>>
>> On Mon, Aug 15, 2016 at 8:15 PM,
On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
> 28.08.2016 09:13, Amit Kapila:
>
> On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova
> <a.lubennik...@postgrespro.ru> wrote:
>
>
> So the patch is correc
r.
I agree with you unless it shows benefit on somewhat more usual
scenario's, we should not accept it. So shouldn't we wait for results
of other workloads like simple-update or tpc-b on bigger machines
before reaching to conclusion?
--
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, Sep 10, 2016 at 5:02 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Aug 30, 2016 at 8:01 AM, Andres Freund <and...@anarazel.de> wrote:
>> On 2016-08-30 07:57:19 +0530, Amit Kapila wrote:
>>> I will write such a test case either in this week o
(aka don't call _bt_log_reuse_page()), if the page is
new, as the only purpose of that log is to handle conflict based on
transaction id stored in special area which will be anyway zero.
--
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
eral, I thought the tests done till now are sufficient to prove
the importance of work, but if still Andres and others have doubt and
they want to test some specific cases, then sure we can do more
performance benchmarking.
Mark, thanks for supporting the case for improving Hash Indexes.
[1] -
h
On Sat, Sep 17, 2016 at 11:25 PM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
> On 09/17/2016 07:05 AM, Amit Kapila wrote:
>>
>> On Sat, Sep 17, 2016 at 9:17 AM, Tomas Vondra
>> <tomas.von...@2ndquadrant.com> wrote:
>>>
>>> On 09/14/2016
On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov <a.igna...@postgrespro.ru> wrote:
>
> On 16.09.2016 16:50, Amit Kapila wrote:
>>
>>
>> Can you try by setting force_parallel_mode = off;? I think it is
>> sending the whole function execution to
postgresql.org/message-id/CAA4eK1%2BQ_DdJ28qXYSHZiBKNf2MY1QFrv5XAOAw4ZXHw4TPMxA%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 subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h is again OLTP
focussed workload) on 9.5 based code has found that CLogControlLock
has the significantly high contention. They were using
synchronous_commit=off in their settings. Now, it is quite possible
that with improvements done in 9.6, the contention they are seeing
will be
On Sat, Sep 17, 2016 at 9:12 AM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
> On 09/17/2016 05:23 AM, Amit Kapila wrote:
>>
>> The difference between these and tests performed by Dilip is that he
>> has lesser savepoints. I think if you want to try it aga
the question is why Dilip sees +30% improvement, while my results are
> almost exactly the same. Looking at Dilip's benchmark, I see he only ran the
> test for 10 seconds, and I'm not sure how many runs he did, warmup etc.
> Dilip, can you provide additional info?
>
> I'll ask someone
e = off;? I think it is
sending the whole function execution to worker due to
force_parallel_mode.
--
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
to improve
hash index. However, each time I try to update them, I find that it
is easy to follow the code than to read and understand the existing
algorithm written in above form from README.
Do others find it useful to maintain the algorithms in above form?
--
With Regards,
Amit Kapila
On Thu, Sep 15, 2016 at 10:38 PM, Jesper Pedersen
<jesper.peder...@redhat.com> wrote:
> On 09/15/2016 02:03 AM, Amit Kapila wrote:
>>>
>>> Same thing here - where the fields involving the hash index aren't
>>> updated.
>>>
>>
>>
On Thu, Sep 15, 2016 at 7:53 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2016-05-10 17:39:22 +0530, Amit Kapila wrote:
>> For making hash indexes usable in production systems, we need to improve
>> its concurrency and make them crash-safe by WAL lo
On Thu, Sep 15, 2016 at 7:25 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Sep 15, 2016 at 2:13 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> One other point, I would like to discuss is that currently, we have a
>> concept for tracking active hash scans
responding code from hashbegin/end scan, but retain that hashscan.c
for future improvements.
I am posting this as a separate mail to avoid it getting lost as one
of the points in long list of review points discussed.
Thoughts?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Thu, Sep 15, 2016 at 12:43 AM, Jesper Pedersen
<jesper.peder...@redhat.com> wrote:
> Hi,
>
> On 09/14/2016 07:24 AM, Amit Kapila wrote:
>
>>> UPDATE also sees an improvement.
>>>
>>
>> Can you explain this more? Is it more compar
On Thu, Sep 15, 2016 at 4:44 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Tue, May 10, 2016 at 5:09 AM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>>
>>
>> Although, I don't think it is a very good idea to take any performance
>> data wit
ible way to change that now.
>
I think it is possible without breaking pg_upgrade, if we match all
items of a page at once (and save them as local copy), rather than
matching item-by-item as we do now. We are already doing similar for
btree, refer explanation of BTScanPosItem and BTScanPo
ext version of the patch.
--
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, Sep 14, 2016 at 12:29 AM, Jesper Pedersen
<jesper.peder...@redhat.com> wrote:
> On 09/13/2016 07:26 AM, Amit Kapila wrote:
>>
>> Attached, new version of patch which contains the fix for problem
>> reported on write-ahead-log of hash index thread [1].
>&
On Tue, Sep 13, 2016 at 5:46 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Sep 8, 2016 at 12:32 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> Hmm. I think page or block is a concept of database systems and
>> buckets is a general concept used in h
On Tue, Sep 13, 2016 at 6:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> While working on write-ahead-logging of hash indexes, I noticed that
>> this function allocates buckets in batches and the mechanism it uses
>&g
%2BSiRSQBzEFpnsSmxZKingrRH7WNyWULJeEJSj1-%3D0w%40mail.gmail.com
[2] - https://commitfest.postgresql.org/10/741/
--
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
Attached, new version of patch which contains the fix for problem
reported on write-ahead-log of hash index thread [1].
[1] -
https://www.postgresql.org/message-id/CAA4eK1JuKt%3D-%3DY0FheiFL-i8Z5_5660%3D3n8JUA8s3zG53t_ArQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http
to unpin the old primary bucket buffer twice when the new bucket
has additional overflow pages. I will post the updated patch on
concurrent hash index thread. Once, I post the patch, it is better if
you try to reproduce the issue once more.
Thanks to Ashutosh Sharma who has offlist shared the call sta
On Tue, Sep 13, 2016 at 3:58 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
> On 13/09/16 01:20, Jesper Pedersen wrote:
>>
>> On 09/01/2016 11:55 PM, Amit Kapila wrote:
>>>
>>> I have fixed all other issues you have raised. Updat
On Sun, Sep 11, 2016 at 3:01 PM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
> On 11/09/16 19:16, Mark Kirkwood wrote:
>
>>
>>
>> On 11/09/16 17:01, Amit Kapila wrote:
>>>
>>> ...Do you think we can do some read-only
>>> workload b
ild without enable-asserts.
>
> Any ideas on how best to go about investigating this?
>
I think these symptoms indicate the bug in concurrent hash index
patch, but it could be that the problem can be only revealed with WAL
patch. Is it possible to just try this with concurrent hash index
pa
801 - 900 of 3337 matches
Mail list logo
