On Fri, 11 Mar 2022 at 04:29, Nikita Glukhov
wrote:
>
>
> On 04.02.2022 05:47, Tomas Vondra wrote:
>
> On 1/25/22 17:56, Mahendra Singh Thalor wrote:
> >
>
> ...
>
> For the last few days, I was trying to understand these patches, and
based on Tomas's su
en keep at
least frequencies for the non-analyzed paths.
Next, I will take the latest patches from Nikita's last email and I will do
more tests.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
retty
328 kB
(1 row)
--
*Without json patches:*
postgres=# analyze test ;
ANALYZE
*Time: 120.864* ms
postgres=# SELECT pg_size_pretty(
pg_total_relation_size('pg_catalog.pg_statistic') );
pg_size_pretty
272 kB
I haven't found the root cause of t
Thanks Dilip and Bharath for the review.
I am working on review comments and will post an updated patch.
On Wed, 10 Nov 2021 at 15:31, Bharath Rupireddy
wrote:
>
> On Wed, Oct 27, 2021 at 1:02 AM Mahendra Singh Thalor
> wrote:
> > On Mon, 3 Aug 2020 at 15:02, Daniel Gu
ook v3[1] patch from this thread and re-based on commit
head(5fedf7417b69295294b154a21).
Please find the attached patch for review.
link [1] : v3 patch
<https://www.postgresql.org/message-id/CANXE4TeinQdw%2BM2Or0kTR24eRgWCOg479N8%3DgRvj9Ouki-tZFg%40mail.gmail.com>
--
Thanks and Regards
Ma
On Sun, 22 Aug 2021 at 22:53, Sadhuprasad Patro wrote:
>
> > On 2021/08/20 11:07, Mahendra Singh Thalor wrote:
> > > 1)
> > > Resets statistics for a single table or index in the
current database
> > > -to zero.
> > > +
On Fri, 20 Aug 2021 at 07:37, Mahendra Singh Thalor wrote:
>
> On Fri, 20 Aug 2021 at 06:32, Sadhuprasad Patro wrote:
> >
> > > If we do support resetting the stats for shared tables in
> > > 'pg_stat_reset', which is for DB level,
> > > then th
* table.*
table should be replaced with 'object' as we have table, index, toast for
shared tables and if we can modify the above comment with some additional
info, then it will be good.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Wed, 11 Aug 2021 at 09:17, Dilip Kumar wrote:
>
> On Tue, Aug 10, 2021 at 10:49 PM Mahendra Singh Thalor
> wrote:
>
> > I checked this and found that we already have one process "stats
> > collector" and in v02 patch, we are sending requests to collect sta
On Tue, 10 Aug 2021 at 22:32, Mahendra Singh Thalor wrote:
>
> On Tue, 10 Aug 2021 at 21:53, Sadhuprasad Patro wrote:
> >
> > > As of now, we are adding handling inside pg_stat_reset for shared
> > > tables but I think we can add a new function with the name of
>
be better if we can reset stats in
pgstat_recv_resetcounter for shared tables also because shared tables are
not much in counting so it will be good if we reset in one function only. I
will debug this part more and will see.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Mon, 9 Aug 2021 at 11:07, Mahendra Singh Thalor
wrote:
>
> Hi,
> I am able to hit "ERROR: cache lookup failed for function %d" while I am
dropping function from another session.
>
> Reproducible steps are as(I tried on current head d8a75b1308b133502ae3):
>
>
.c:1430
> #15 0x55e0b808dbe9 in main (argc=3, argv=0x55e0ba8fee70) at main.c:199
>
cache lookup failed errors are never an expected behavior(Thanks Robert
Hass for your opinion) so I think we should fix this error.
I haven't debugged it so I will debug it and will post my findings in the
coming days.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
; > > pg_stat_reset_single_table_counters
> > > -
> > >
> > > (1 row)
> > >
> > > postgres=# SELECT * FROM pg_statio_all_tables where relid =
> > > 'pg_database'::regclass::oid;
> > &g
On Sat, 7 Aug 2021 at 11:49, Mahendra Singh Thalor wrote:
>
> On Sat, 7 Aug 2021 at 00:13, Mahendra Singh Thalor wrote:
> >
> > On Fri, 6 Aug 2021 at 21:17, Dilip Kumar wrote:
> > >
> > > On Fri, Aug 6, 2021 at 8:53 PM Himanshu Upadhyaya
&g
On Sat, 7 Aug 2021 at 00:13, Mahendra Singh Thalor
wrote:
>
> On Fri, 6 Aug 2021 at 21:17, Dilip Kumar wrote:
> >
> > On Fri, Aug 6, 2021 at 8:53 PM Himanshu Upadhyaya
> > wrote:
> > >
> > > Hi Sadhu,
> > >
> > > Patch working as expe
e | relname | heap_blks_read | heap_blks_hit |
idx_blks_read | idx_blks_hit | toast_blks_read | toast_blks_hit |
tidx_blks_read | tidx_blks_hit
---++-++---+---+--+-+++---
1262 | pg_catalog | pg_database | 0 | 0 |
2 |0 | 0 | 0 |
0 | 0
(1 row)
postgres=#
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
v0002-pg_stat_reset-and-pg_stat_reset_single_table_counter.patch
Description: Binary data
d -- SharedDependRelationId 1214
7. pg_shseclabel -- SharedSecLabelRelationId 3592
8. pg_db_role_setting -- DbRoleSettingRelationId 2694
9. pg_replication_origin -- ReplicationOriginRelationId 6000
10. pg_subscription -- SubscriptionRelationId 6100
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://w
ing to do if not there.
*/
dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
-
if (!dbentry)
return;
I think, by mistake, you removed one line in the patch.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
> if (result.index > 0) /* result.index is garbage or invalid here) */
>
> regards,
> Ranier Vilela
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Tue, 6 Apr 2021 at 19:14, Bharath Rupireddy
wrote:
>
> On Tue, Apr 6, 2021 at 6:09 PM Michael Paquier wrote:
> >
> > On Mon, Mar 22, 2021 at 10:58:17AM +0530, Mahendra Singh Thalor wrote:
> > > Your changes look to fine me and I am also not getting any failure. I
On Tue, 23 Mar 2021 at 02:43, Justin Pryzby wrote:
>
> On Mon, Mar 22, 2021 at 02:10:49PM +0530, Mahendra Singh Thalor wrote:
> > Hi Hackers,
> >
> > Commit 906bfcad7ba7c has improved handling for "UPDATE ... SET
> > (column_list) = row_constructor",
e above test case is
passing in all the branches.
This looks like a bug.
Thoughts?
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
ev system with the
> attached patch.
>
>
> Thoughts?
Your changes look to fine me and I am also not getting any failure. I
think we should back-patch all the branches.
Patch is applying to all the branches(till v95) and there is no failure.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
usage in
> README.tuplock would definitely be useful, especially since the combination
> isn't always produced. How about adding something like:
>
> HEAP_KEYS_UPDATED
> This bit lives in t_infomask2. If set, indicates that the XMAX updated
> this tuple and changed the key values, or it deleted the tuple.
> + It can also be set in combination of HEAP_XMAX_LOCK_ONLY.
> It's set regardless of whether the XMAX is a TransactionId or a MultiXactId.
Make sense. Please can you update this?
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
in exec_simple_query (query_string=0x5612a787b570
> "UPDATE t1 SET val = 'hoho' WHERE id = 2;") at postgres.c:1240
> #18 0x5612a612b8dd in PostgresMain (argc=1, argv=0x7ffc8b5e3790,
> dbname=0x5612a78a74f0 "postgres", username=0x5612a78a74c8 "
mation, so I think we should back-patch to 13. The
> second one is to add additional vacuum error context information, so
> that is for only HEAD. Does that make sense? Also, let me know if you
> have any more comments.
Thanks Amit for updating the patch. All changes in v7-02 look fine to me.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
>
> --
> With Regards,
> Amit Kapila.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
Thanks Sawada and Justin.
On Sun, 2 Aug 2020 at 09:33, Masahiko Sawada
wrote:
>
> On Sat, 1 Aug 2020 at 16:02, Mahendra Singh Thalor wrote:
> >
> > Thanks Justin.
> >
> > On Sat, 1 Aug 2020 at 11:47, Justin Pryzby wrote:
> > >
> > > On Fri, Jul 3
t; whoops
>
> > On Wed, Jul 29, 2020 at 12:35:17AM +0530, Mahendra Singh Thalor wrote:
> > > > Here:
> > > >
> > > > @@ -1924,14 +1932,22 @@ lazy_vacuum_page(Relation onerel, BlockNumber
> > > > blkno, Buffer buffer,
> > > &
Thanks Justin, Sawada and Michael for reviewing.
On Mon, 27 Jul 2020 at 16:43, Justin Pryzby wrote:
>
> On Fri, Jul 24, 2020 at 11:18:43PM +0530, Mahendra Singh Thalor wrote:
> > Hi hackers,
> > We discussed in another email thread[1], that it will be helpful if we can
> &
Thanks Michael for looking into this.
On Sat, 25 Jul 2020 at 15:02, Michael Paquier wrote:
>
> On Fri, Jul 24, 2020 at 11:18:43PM +0530, Mahendra Singh Thalor wrote:
> > In commit b61d161(Introduce vacuum errcontext to display additional
> > information), we added vacuum err
errmsg_internal("for block %u and offnum %u, found xmin %u from before
relfrozenxid %u",
+ ItemPointerGetBlockNumber(tid),
+ ItemPointerGetOffsetNumber(tid),
xid, relfrozenxid)));
Attaching v01_0002 patch for this method.
Please let me know your thoughts.
[1] : http://postgr.es/m/
On Fri, 29 May 2020 at 15:52, Amit Kapila wrote:
>
> On Wed, May 27, 2020 at 5:19 PM Mahendra Singh Thalor
wrote:
>>
>> On Tue, 26 May 2020 at 16:46, Amit Kapila
wrote:
>>
>> Hi all,
>> On the top of v16 patch set [1], I did some testing for DDL's a
ix (DDL & DML), it is 2-10%.
why are we seeing 11-13 % of the extra wall, basically, the amount of
extra WAL is not very high but the amount of WAL generated with add column
int/date is just ~1000 bytes so additional 100 bytes will be around 10% and
for add column text it is ~35000 bytes so % is less. For text, these
~35000 bytes are due to toast.
[1]:
https://www.postgresql.org/message-id/CAFiTN-vnnrk580ucZVYnub_UQ-ayROew8fQ2Yn5aFYMeF0U03w%40mail.gmail.com
[2]:
https://docs.google.com/spreadsheets/d/1g11MrSd_I39505OnGoLFVslz3ykbZ1nmfR_gUiE_O9k/edit?usp=sharing
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Wed, 29 Apr 2020 at 11:15, Mahendra Singh Thalor wrote:
>
> On Fri, 24 Apr 2020 at 11:55, Dilip Kumar wrote:
> >
> > On Thu, Apr 23, 2020 at 2:28 PM Erik Rijkers wrote:
> > >
> > > On 2020-04-23 05:24, Dilip Kumar wrote:
> > > > On
On Wed, 8 Apr 2020 at 22:11, Justin Pryzby wrote:
>
> On Wed, Apr 08, 2020 at 11:57:08AM -0400, Robert Haas wrote:
> > On Wed, Apr 8, 2020 at 10:25 AM Mahendra Singh Thalor
> > wrote:
> > > I think, Tushar point is that either we should allow both
> > > v
a clear error message which matches what you tried to do.
>
I think, Tushar point is that either we should allow both
vacuum(parallel 0, full 1) and vacuum(parallel 1, full 0) or in the
both cases, we should through error.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
6008137499a in ServerLoop () at postmaster.c:1691
#15 0x560081373e63 in PostmasterMain (argc=3, argv=0x560082189020) at
postmaster.c:1400
#16 0x5600811d37ea in main (argc=3, argv=0x560082189020) at main.c:210
Here, stats is null so it is crashing.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Wed, 4 Mar 2020 at 12:03, Dilip Kumar wrote:
>
> On Wed, Mar 4, 2020 at 11:45 AM Mahendra Singh Thalor
> wrote:
> >
> > On Mon, 24 Feb 2020 at 15:39, Amit Kapila wrote:
> > >
> > > On Thu, Feb 20, 2020 at 8:06 AM Andres Freund wrote:
> > > &
On Thu, 5 Mar 2020 at 13:54, Dilip Kumar wrote:
>
> On Thu, Mar 5, 2020 at 12:15 PM Amit Kapila wrote:
> >
> > On Wed, Mar 4, 2020 at 11:45 AM Mahendra Singh Thalor
> > wrote:
> > >
> > > On Mon, 24 Feb 2020 at 15:39, Amit Kapila wrote:
> > &g
On Wed, 4 Mar 2020 at 12:03, Dilip Kumar wrote:
>
> On Wed, Mar 4, 2020 at 11:45 AM Mahendra Singh Thalor
> wrote:
> >
> > On Mon, 24 Feb 2020 at 15:39, Amit Kapila wrote:
> > >
> > > On Thu, Feb 20, 2020 at 8:06 AM Andres Freund wrote:
> > > &
kCycleRecurseMember just ignores these two types
> of locks by checking the lock tag.
Thanks Amit for summary.
Based on above 3 points, here attaching 2 patches for review.
1. v01_0001-Conflict-EXTENTION-lock-in-group-member.patch (Patch by Dilip Kumar)
Basically this patch is for point b and c.
2
not actually sure that
> it is autovacuum's job to handle that better.
>
> Any thoughts?
Hi,
Patch looks good to me and it is fixing the assert failure.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
suggestions. I have started working on the
implementation based on the suggestion. I will post a patch for this
in few days.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Sat, 8 Feb 2020 at 00:27, Mahendra Singh Thalor
wrote:
>
> On Thu, 6 Feb 2020 at 09:44, Amit Kapila wrote:
> >
> > On Thu, Feb 6, 2020 at 1:57 AM Mahendra Singh Thalor
wrote:
> > >
> > > On Wed, 5 Feb 2020 at 12:07, Masahiko Sawada
wrote:
> > >
On Thu, 6 Feb 2020 at 09:44, Amit Kapila wrote:
>
> On Thu, Feb 6, 2020 at 1:57 AM Mahendra Singh Thalor
wrote:
> >
> > On Wed, 5 Feb 2020 at 12:07, Masahiko Sawada
wrote:
> > >
> > > On Mon, Feb 3, 2020 at 8:03 PM Amit Kapila
wrote:
> > > >
&
8.49 %
32 392.881863
388.470622-1.12 %
56 551.753235
528.018852 -4.30 %
60 648.273767
653.251507 +0.76 %
64 645.975124
671.322140 +3.92 %
66
he single patch. What do we think
> > > > about backpatching this?
> > >
> > > No objection to the patch for HEAD, but it does not seem like
> > > back-patch material: it is not fixing a bug.
> > >
> >
> > Okay, I will commit this early next week
On Tue, 28 Jan 2020 at 20:36, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
> wrote:
> > I can see one warning on HEAD.
> >
> > jsonapi.c: In function ‘json_errdetail’:
> > jsonapi.c:1068:1: warning: control reaches end of non
On Tue, 28 Jan 2020 at 12:32, Amit Kapila wrote:
>
> On Tue, Jan 28, 2020 at 12:04 PM Mahendra Singh Thalor
> wrote:
> >
> > On Tue, 28 Jan 2020 at 08:14, Amit Kapila wrote:
> > >
> > > On Tue, Jan 28, 2020 at 2:13 AM Mahendra Singh Thalor
> > >
On Tue, 28 Jan 2020 at 08:14, Amit Kapila wrote:
>
> On Tue, Jan 28, 2020 at 2:13 AM Mahendra Singh Thalor
> wrote:
> >
> > On Sat, 25 Jan 2020 at 12:11, Amit Kapila
wrote:
> > >
> > > On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
> > >
On Sat, 25 Jan 2020 at 12:11, Amit Kapila wrote:
>
> On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
> wrote:
> >
> > On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor
wrote:
> > >
> > > On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
> > &
rmtree.c, pgfnames.c) which could perhaps be
> generalized. I think I'll start a new thread about that.
>
Hi,
I can see one warning on HEAD.
jsonapi.c: In function ‘json_errdetail’:
jsonapi.c:1068:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
Attaching a patch to fix warning.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
Fixed_compiler_warning_json_errdetail.patch
Description: Binary data
On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor wrote:
>
> On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
> wrote:
> >
> > On Wed, 22 Jan 2020 at 11:23, Amit Kapila wrote:
> > >
> > > On Wed, Jan 22, 2020 at 7:14 AM Masahiko Sawada
> > > w
[1]:
https://www.postgresql.org/message-id/CA%2Bfd4k6DgwtQSr4%3DUeY%2BWbGuF7-oD%3Dm-ypHPy%2BsYHiXZc%2BhTUQ%40mail.gmail.com
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
tion constraint of relation "part_1" is violated b some row
> >
>
> +1 for the second option suggested by Beena.
I fixed above comment and updated expected .out files. Attaching
updated patches.
To make review simple, I made 3 patches as:
v4_0001_rationalize_constrain
s will no longer be true.
>
> Attached the updated version patch.
>
Thanks Sawada-san for the re-based patch.
I reviewed and tested this patch. Patch looks good to me.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Tue, 21 Jan 2020 at 10:51, Amit Kapila wrote:
>
> On Mon, Jan 6, 2020 at 6:31 PM Mahendra Singh Thalor
wrote:
> >
> > On Sat, 6 Jul 2019 at 09:53, Amit Kapila
wrote:
> > >
> > > On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera <
alvhe...@2ndquadrant.co
psql you can use
> \set VERBOSITY verbose
>
> In psql you can also use \errverbose after an error to print those
> fields.
Thanks for the explanation.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
ers.
+ */
This comment is confusing me. I think, "then" should be replaced with
"than".
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Thu, 16 Jan 2020 at 08:22, Amit Kapila wrote:
>
> On Thu, Jan 16, 2020 at 1:02 AM Mahendra Singh Thalor
> wrote:
> >
> > On Wed, 15 Jan 2020 at 19:31, Mahendra Singh Thalor
> > wrote:
> > >
> > > On Wed, 15 Jan 2020 at 19:04, Mahendra Singh Th
On Wed, 15 Jan 2020 at 19:31, Mahendra Singh Thalor wrote:
>
> On Wed, 15 Jan 2020 at 19:04, Mahendra Singh Thalor
> wrote:
> >
> > On Wed, 15 Jan 2020 at 17:27, Amit Kapila wrote:
> > >
> > > On Wed, Jan 15, 2020 at 10:05 AM Masahiko Sawada
> > >
On Wed, 15 Jan 2020 at 19:04, Mahendra Singh Thalor wrote:
>
> On Wed, 15 Jan 2020 at 17:27, Amit Kapila wrote:
> >
> > On Wed, Jan 15, 2020 at 10:05 AM Masahiko Sawada
> > wrote:
> > >
> > > Thank you for updating the patch! I have a few small comme
ERROR: parallel option requires a value between 0 and 1024
LINE 1: VACUUM (PARALLEL) tmp;
^
postgres=#
Because above error is added in this parallel patch, so we should have test
case for this to increase code coverage.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Tue, 14 Jan 2020 at 17:16, Mahendra Singh Thalor wrote:
>
> On Tue, 14 Jan 2020 at 16:17, Mahendra Singh Thalor
> wrote:
> >
> > On Tue, 14 Jan 2020 at 10:06, Masahiko Sawada
> > wrote:
> > >
> > > On Tue, 14 Jan 2020 at 03:20, Mahendra Singh Tha
On Tue, 14 Jan 2020 at 16:17, Mahendra Singh Thalor
wrote:
>
> On Tue, 14 Jan 2020 at 10:06, Masahiko Sawada
> wrote:
> >
> > On Tue, 14 Jan 2020 at 03:20, Mahendra Singh Thalor
wrote:
> > >
> > > On Fri, 10 Jan 2020 at 15:51, Sergei Kornilov wrote:
&
On Tue, 14 Jan 2020 at 10:06, Masahiko Sawada
wrote:
>
> On Tue, 14 Jan 2020 at 03:20, Mahendra Singh Thalor
> wrote:
> >
> > On Fri, 10 Jan 2020 at 15:51, Sergei Kornilov wrote:
> > >
> > > Hi
> > > Thank you for update! I
hen we can avoid
multiple function calling of skip_parallel_vacuum_index and if there
is no index which can't performe parallel vacuum, then we will not
call vacuum_indexes_leader as head of list pointing to null. (we can
save unnecessary calling of vacuum_indexes_leader)
Thoughts?
--
Thanks
On Sat, 11 Jan 2020 at 19:48, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
>
> On Sat, 11 Jan 2020 at 13:18, Amit Kapila wrote:
> >
> > On Sat, Jan 11, 2020 at 9:23 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, 10 Jan 2020 at 2
drop cascades to table test1
DROP SCHEMA
postgres=# \d
Did not find any relations.
postgres=# create temporary table test1 (a int);
CREATE TABLE
postgres=# \d
Did not find any relations.
postgres=#
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
t;
> And therefore we turn off the parallel vacuum for the remaining tables... Can
> we improve this case?
Good point.
Yes, we should improve this. I tried to fix this. Attaching a delta
patch that is fixing both the comments.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
v44-0002-delta_Allow-vacuum-command-to-process-indexes-in-parallel.patch
Description: Binary data
n main (argc=3, argv=0x2ce2290) at main.c:210
I think, before committing 1st patch, we should fix this crash also and
then we should commit all the patches.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Thu, 9 Jan 2020 at 17:31, Sergei Kornilov wrote:
>
> Hello
>
> I noticed that parallel vacuum uses min_parallel_index_scan_size GUC to skip
> small indexes but this is not mentioned in documentation for both vacuum
> command and GUC itself.
>
> + /* Determine the number of parallel work
was 2 spaces.
Other than that patch looks fine to me.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
;t finalized error messages.
I verified Robert's point of for partition tables also. With the error, we
are adding relation name of "child table" and i think, it is correct.
Please review attached patch and let me know feedback.
Thanks and Regards
Mahendra Singh Thalor
Enterpri
On Fri, 3 Jan 2020 at 00:40, Tom Lane wrote:
>
> Robert Haas writes:
> > On Thu, Jan 2, 2020 at 12:59 PM Mahendra Singh wrote:
> >> While reading code and doing some testing, I found that if we create a
> >> temporary table with same name as we created a normal(g
> > ) ;
> > (b) Vacuum (Parallel ) ; If user specifies
> > parallel_degree as 0, then disable parallelism.
> > (c) ... Any better ideas?
>
> IMHO, it's better to keep the parallelism enables by default. Because
> if the user is giving an explic
.
If this is a bug, then please let me know. I will be happy to fix this.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
porated the review
> comments, a few fix and the patch for
> PARALLEL_VACUUM_DISABLE_LEADER_PARTICIPATION. 0001 patch is the same
> as previous version.
I verified my all review comments in v40 patch set. All are fixed.
v40-0002-Add-a-parallel-option-to-the-VACUUM-command.patch doesn't
apply on HEAD. Please send re-based patch.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Thu, 26 Dec 2019 at 23:21, Tom Lane wrote:
>
> Mahendra Singh writes:
> > I think, we can add a regression test for this.
> > postgres=# create temporary table temp(c1 int);
> > CREATE TABLE
> > postgres=# drop schema pg_temp_3 cascade ;
> > ERROR: cannot
l
the temp table schema but it is not drooping.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
On Tue, 24 Dec 2019 at 02:41, Peter Geoghegan wrote:
>
> On Mon, Dec 23, 2019 at 11:05 AM Mahendra Singh wrote:
> > From above example, we can see that after deleting all the tuples from
> > table and firing vacuum command, size of table is reduced but size of index
>
On Wed, 25 Dec 2019 at 07:52, Michael Paquier wrote:
>
> On Tue, Dec 24, 2019 at 04:50:58PM +0530, Mahendra Singh wrote:
> > We can fix this problem by either one way 1) reset myTempNamespace to
> > invalid while drooping schema of temp table 2) should not allow to drop
> >
Hi hackers,
In other thread "[HACKERS] Block level parallel vacuum"[1], Prabhat Kumar
Sahu reported a random assert failure but he got only once and he was not
able to reproduce it. In that thread [2], Amit Kapila suggested some points
to reproduce assert. I tried to reproduce and I was able to
see that after deleting all the tuples from
table and firing vacuum command, size of table is reduced but size of index
relation is same as before vacuum.
Please let me your thoughts.
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
g_indg_On Mon, 23 Dec 2019 at 16:11, Amit Kapila
wrote:
>
> On Fri, Dec 20, 2019 at 12:13 PM Masahiko Sawada
> wrote:
> >
> > I've attached the updated version patch that incorporated the all
> > review comments I go so far.
> >
>
> I have further edited the first two patches posted by you. The
On Fri, 20 Dec 2019 at 17:17, Prabhat Sahu
wrote:
>
> Hi,
>
> While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got a
> server crash on PG Head+V36_patch.
> Changed configuration parameters and Stack trace are as below:
>
> autovacuum = on
> max_worker_processes = 4
> shared
On Wed, 18 Dec 2019 at 12:07, Amit Kapila wrote:
>
> [please trim extra text before responding]
>
> On Wed, Dec 18, 2019 at 12:01 PM Mahendra Singh wrote:
> >
> > On Tue, 10 Dec 2019 at 00:30, Mahendra Singh wrote:
> > >
> > >
> > > 3.
> >
On Tue, 10 Dec 2019 at 00:30, Mahendra Singh wrote:
>
> On Fri, 6 Dec 2019 at 10:50, Amit Kapila wrote:
> >
> > On Thu, Dec 5, 2019 at 7:44 PM Robert Haas wrote:
> > >
> > > I think it might be a good idea to change what we expect index AMs to
> > >
On Wed, 18 Dec 2019 at 07:23, Michael Paquier wrote:
>
> On Tue, Dec 17, 2019 at 11:40:17PM +0530, Mahendra Singh wrote:
> > I found some inconsistency in alphabetical order in
> > src/backend/tsearch/Makefile, src/backend/utils/Makefile and
> > src/pl/plpython/Makefile f
On Tue, 17 Dec 2019 at 18:07, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
>
> On Fri, 13 Dec 2019 at 15:50, Amit Kapila wrote:
> >
> > On Fri, Dec 13, 2019 at 11:08 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, 13 Dec 2019 at 14:19, Amit Kapila
wrote:
> > > >
> > > > > > >
> >
On Fri, 8 Nov 2019 at 14:38, Michael Paquier wrote:
>
> On Thu, Nov 07, 2019 at 12:02:04PM -0500, Tom Lane wrote:
> > I don't think it'd be a great idea to change parallel_schedule like
> > that. Independently adding test scripts to the same parallel batch
> > probably won't end well: you might e
On Fri, 6 Dec 2019 at 10:50, Amit Kapila wrote:
>
> On Thu, Dec 5, 2019 at 7:44 PM Robert Haas wrote:
> >
> > I think it might be a good idea to change what we expect index AMs to
> > do rather than trying to make anything that they happen to be doing
> > right now work, no matter how crazy. In p
On Thu, 5 Dec 2019 at 19:54, Robert Haas wrote:
>
> [ Please trim excess quoted material from your replies. ]
>
> On Thu, Dec 5, 2019 at 12:27 AM Dilip Kumar wrote:
> > I agree that there is no point is first to spawn more workers to get
> > the work done faster and later throttle them. Basicall
On Tue, 3 Dec 2019 at 16:27, Amit Kapila wrote:
> On Tue, Dec 3, 2019 at 4:25 PM Amit Kapila
> wrote:
>
>> Few other things, I would like you to consider.
>> 1. I think disable_parallel_leader_participation related code can be
>> extracted into a separate patch as it is mainly a debug/test aid.
On Sat, 30 Nov 2019 at 19:18, Sergei Kornilov wrote:
> Hello
>
> Its possible to change order of index processing by parallel leader? In
> v35 patchset I see following order:
> - start parallel processes
> - leader and parallel workers processed index lixt and possible skip some
> entries
> - aft
On Thu, 28 Nov 2019 at 13:32, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Wed, 27 Nov 2019 at 19:21, Mahendra Singh wrote:
> >
> >
> > Thanks for the re-based patches.
> >
> > On the top of v35 patch, I can see one compilation war
On Wed, 27 Nov 2019 at 23:14, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Wed, 27 Nov 2019 at 13:26, Amit Kapila wrote:
> >
> > On Wed, Nov 27, 2019 at 8:14 AM Amit Kapila
> wrote:
> > >
> > > On Wed, Nov 27, 2019 at 12:52 AM Masahiko Sawada
> > > wrote:
> > > >
> > > >
> > >
On Wed, 27 Nov 2019 at 08:14, Amit Kapila wrote:
> On Wed, Nov 27, 2019 at 12:52 AM Masahiko Sawada
> wrote:
> >
> >
> > I've incorporated the comments I got so far including the above and
> > the memory alignment issue.
> >
>
> Thanks, I will look into the new version. BTW, why haven't you pos
On Mon, 11 Nov 2019 at 17:56, Amit Kapila wrote:
>
> On Mon, Nov 11, 2019 at 5:14 PM Dilip Kumar wrote:
> >
> > On Mon, Nov 11, 2019 at 4:23 PM Amit Kapila
wrote:
> > >
> > > ..
> > > > I have tested the same with some other workload(test file attached).
> > > > I can see the same behaviour with
1 - 100 of 109 matches
Mail list logo