Re: [HACKERS] UPDATE of partition key

On 21 November 2017 at 17:24, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 13 November 2017 at 18:25, David Rowley <david.row...@2ndquadrant.com> > wrote: >> >> 30. The following chunk of code is giving me a headache trying to >>

Re: [HACKERS] UPDATE of partition key

On 24 November 2017 at 10:52, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/11/23 21:57, Amit Khandekar wrote: >> If we collect the partition keys in expand_partitioned_rtentry(), we >> need to pass the root relation also, so that we can convert the >&g

Re: [HACKERS] UPDATE of partition key

UPDATE statement trigger was defined for the target table, not the leaf partition. Barring any objections, I am going to send a revised patch that fixes the above issue as described. Thanks -Amit Khandekar wco_rls_issue.sql Description: Binary data

Re: Needless additional partition check in INSERT?

On 14 May 2018 at 10:30, David Rowley <david.row...@2ndquadrant.com> wrote: > On 14 May 2018 at 16:49, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> On 2018/05/11 18:43, Amit Khandekar wrote: >>> This looks better (it will avoid unne

Re: Needless additional partition check in INSERT?

the if conditions would get simpler : if (resultRelInfo->ri_PartitionRoot == NULL || (resultRelInfo->ri_TrigDesc && resultRelInfo->ri_TrigDesc->trig_insert_before_row)) check_partition_constr = true; else check_partition_constr = false; -- Thanks, -Amit Khandekar

Re: Needless additional partition check in INSERT?

On 11 May 2018 at 14:50, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 10 May 2018 at 15:26, David Rowley <david.row...@2ndquadrant.com> wrote: >> Yeah, the comments do need work. In order to make it a bit easier to >> document I changed the way that ch

Re: Concurrency bug in UPDATE of partition-key

y show how many times the trigger has executed. So I will go ahead and do that. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

the behavior clear and consistent. >> > > I agree with your analysis and proposed change. However, I think in > practice, it might not lead to any bug as in the loop, we are > computing parallel_safety and partial_subpaths should be > parallel_safe. Will have a look at this soon. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

+-- Parallel Append is not be used when the subpath depends on the outer param "is not be used" => "is not to be used" -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: AtEOXact_ApplyLauncher() and subtransactions

On 16 June 2018 at 00:03, Amit Khandekar wrote: > The way I am implementing this can be seen in attached > apply_launcher_subtrans_WIP.patch. (check launcher.c changes). I > haven't started testing it yet though. Attached patch passes some basic testing I did. Will do some more testing,

Re: AtEOXact_ApplyLauncher() and subtransactions

On 15 June 2018 at 09:46, Peter Eisentraut wrote: > On 6/5/18 07:02, Amit Khandekar wrote: >> I haven't written a patch for it, but I think we should have a >> separate on_commit_stop_workers for eachyou get subtransaction. At >> subtransaction commit, we replace the on_com

Re: Concurrency bug in UPDATE of partition-key

On 11 June 2018 at 15:29, Amit Kapila wrote: > On Mon, Jun 11, 2018 at 3:02 PM, Amit Kapila wrote: >> On Thu, Jun 7, 2018 at 1:53 PM, Amit Khandekar >> wrote: >>> On 7 June 2018 at 11:44, Amit Kapila wrote: >>>> On Tue, Jun 5, 2018 at 8:03 PM, Amit Khan

Re: Concurrency bug in UPDATE of partition-key

On 19 June 2018 at 13:06, Dilip Kumar wrote: > On Mon, Jun 18, 2018 at 6:19 PM, Amit Khandekar > wrote: >> On 18 June 2018 at 17:56, Amit Kapila wrote: >>> On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar wrote: >>>> Should we also create a test c

Re: Concurrency bug in UPDATE of partition-key

On 8 June 2018 at 16:44, Dilip Kumar wrote: > On Fri, Jun 8, 2018 at 2:23 PM, Dilip Kumar wrote: >> >> On Tue, Jun 5, 2018 at 8:03 PM, Amit Khandekar >> wrote: >>> >>> Attached is a rebased patch version. Also included it in the upcoming >>> commi

AtEOXact_ApplyLauncher() and subtransactions

nised. Effectively, at commit, all the workers are targetted to be stopped, when actually at commit time there is no final change in the tables to be synchronised. What actually we should do is : for each ALTER command we should compare the very first set of tables being synchronised since the la

Re: Concurrency bug in UPDATE of partition-key

Attached is a rebased patch version. Also included it in the upcoming commitfest : https://commitfest.postgresql.org/18/1660/ In the rebased version, the new test cases are added in the existing isolation/specs/partition-key-update-1.spec test. -- Thanks, -Amit Khandekar EnterpriseDB

Re: Concurrency bug in UPDATE of partition-key

On 7 June 2018 at 11:44, Amit Kapila wrote: > On Tue, Jun 5, 2018 at 8:03 PM, Amit Khandekar > wrote: >> >> Attached is a rebased patch version. Also included it in the upcoming >> commitfest : >> https://commitfest.postgresql.org/18/1660/ >> > > Doesn

Re: Concurrency bug in UPDATE of partition-key

pass it back separately. > OTOH, the approach used by Amit Khandekar seems somewhat better as you > can directly return the slot returned by EvalPlanQual in the output > parameter. IIUC, the same technique is already used by > GetTupleForTrigger where it returns the epqslot in

Re: Concurrency bug in UPDATE of partition-key

On 20 June 2018 at 18:54, Amit Kapila wrote: > On Tue, Jun 19, 2018 at 9:33 PM, Amit Khandekar > wrote: >> >> Could not add RAISE statement, because the isolation test does not >> seem to print those statements in the output. Instead, I have dumped >> so

Re: Concurrency bug in UPDATE of partition-key

On 25 June 2018 at 17:20, Amit Kapila wrote: > On Mon, Jun 25, 2018 at 3:06 PM, Amit Khandekar > wrote: >> On 23 June 2018 at 15:46, Amit Kapila wrote: >>>> >>> >>> Why do you need to update when newslot is NULL? Already *epqslot is >>> init

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

On 20 June 2018 at 14:24, Amit Kapila wrote: > On Mon, Jun 18, 2018 at 3:11 PM, Amit Khandekar > wrote: >> On 16 June 2018 at 10:44, Amit Kapila wrote: >>> On Thu, Jun 14, 2018 at 10:05 PM, Tom Lane wrote: >>>> >>>> It looks to me like traversal of

Re: AtEOXact_ApplyLauncher() and subtransactions

On 18 June 2018 at 15:02, Amit Khandekar wrote: > On 16 June 2018 at 00:03, Amit Khandekar wrote: >> The way I am implementing this can be seen in attached >> apply_launcher_subtrans_WIP.patch. (check launcher.c changes). I >> haven't started testing it yet though. > >

Re: Concurrency bug in UPDATE of partition-key

On 26 June 2018 at 17:53, Amit Kapila wrote: > Yeah, so let's leave it as it is in the patch. Ok. > I think now we should wait and see what Alvaro has to say about the overall > patch. Yeah, that's very good that Alvaro is also having a look at this. -- Thanks, -Amit Khandekar Ent

Re: AtEOXact_ApplyLauncher() and subtransactions

Added this into the July 2018 commitfest : https://commitfest.postgresql.org/18/1696/ On 20 June 2018 at 22:22, Amit Khandekar wrote: > On 18 June 2018 at 15:02, Amit Khandekar wrote: >> On 16 June 2018 at 00:03, Amit Khandekar wrote: >>> The way I am implementing this can b

Re: Parallel append plan instability/randomness

On 8 January 2018 at 13:35, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Jan 8, 2018 at 11:26 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Amit Khandekar <amitdkhan...@gmail.com> writes: >>> The fact that b_star gets moved from 5th position to

Re: Parallel append plan instability/randomness

first somehow reproduce this case and see what is going wrong, any > ideas? The fact that b_star gets moved from 5th position to the first position in the scans, indicates that it's cost shoots up from 1.04 to a value greater than 1.16. It does not look like a case where two costs are almos

Re: [HACKERS] UPDATE of partition key

file, which does not have the empty > lines. Still seems a bit surplus. I believe the output file does not have the blank lines present in the .sql file. I was referring to the paragraph in the *.sql* file. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Multi-level hierarchy with parallel append can lead to an extra subplan.

nherit > -> Seq Scan on rm38941_inherit_t1 > -> Seq Scan on rm38941_inherit_t2 > -> Seq Scan on rm38941_union_t1 > (7 rows) > > postgres=# SELECT AVG(c1),SUM(c2) FROM (SELECT c1,c2 FROM RM38941_union_t2 > UNION ALL SELECT c1,c2 FROM RM38941_inherit UNION ALL SELECT c1,c2 FROM > RM38941_union_t1)UA; > avg | sum > --+--- > 248.6917040358744395 | 55083 > (1 row) > > Thanks & Regards, > Rajkumar Raghuwanshi > QMG, EnterpriseDB Corporation -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: [HACKERS] UPDATE of partition key

On 16 January 2018 at 09:17, David Rowley <david.row...@2ndquadrant.com> wrote: > On 16 January 2018 at 01:09, Robert Haas <robertmh...@gmail.com> wrote: >> On Sun, Jan 14, 2018 at 6:57 AM, Amit Khandekar <amitdkhan...@gmail.com> >> wrote: >>> Even where

Re: [HACKERS] UPDATE of partition key

On 13 January 2018 at 02:56, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jan 12, 2018 at 12:23 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >>> (1) if they need it by subplan index, first use >>> subplan_partition_offsets to convert it to a

Re: [HACKERS] Useless code in ExecInitModifyTable

ned table, rather than opening it again. Details : [1] . Sorry for not noticing this potential conflict earlier. Comments welcome. [1] : https://www.postgresql.org/message-id/CAJ3gD9cpyM1L0vTrXzrggR%3Dt6MSZtuy_kge1kagMBi0TSKa_UQ%40mail.gmail.com Thanks -Amit Khandekar On 18 January 2018 at 12

Re: [HACKERS] UPDATE of partition key

ssing the array once we are done with all the offset array elements. Ran the update.sql test with valgrind enabled on my laptop, and the valgrind output now does not show errors. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company fix_valgrind_issue.patch Description: Binary data

Re: [HACKERS] UPDATE of partition key

On 12 January 2018 at 20:24, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jan 12, 2018 at 5:12 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> The reason why I am having map_required field inside a structure along >> with the map, as against a separa

Re: Query running for very long time (server hanged) with parallel append

Thanks Rajkumar for catching this. I will have a look ... -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Query running for very long time (server hanged) with parallel append

at you pointed. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Query running for very long time (server hanged) with parallel append

On 2 February 2018 at 20:46, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Feb 2, 2018 at 1:43 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> The query is actually hanging because one of the workers is in a small >> loop where it iterates over the subpla

Re: Query running for very long time (server hanged) with parallel append

ne in the patch, I have avoided that. But the committer can very well make this change, all though I am not sure myself about the grammar. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company fix_hang_issue_v2.patch Description: Binary data

Re: Query running for very long time (server hanged) with parallel append

On 7 February 2018 at 07:30, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Tue, 6 Feb 2018 13:50:28 -0500, Robert Haas <robertmh...@gmail.com> wrote > in <CA+TgmoYqdC+9U8mLYkUgM=cabt6pzz4r_ynboqdbw-lvuah...@mail.gmail.com> >> On Tue, Feb 6, 20

Re: Query running for very long time (server hanged) with parallel append

On 6 February 2018 at 10:11, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> At Mon, 5 Feb 2018 15:29:27 +0530, Amit Khandekar <amitdkhan...@gmail.com> >> wrote in >> > Attached is a patch that fixes this issue on the above lines. >> >>

Re: In logical replication concurrent update of partition key creates a duplicate record on standby.

On 7 February 2018 at 13:53, amul sul wrote: > Hi, > > If an update of partition key involves tuple movement from one partition to > another partition then there will be a separate delete on one partition and > insert on the other partition made. > > In the logical replication

Re: [HACKERS] UPDATE of partition key

gt; > + /* > + * UPDATEs set the transition capture map only when a new subplan > + * is chosen. But for INSERTs, it is set for each row. So after > + * INSERT, we need to revert back to the map created for UPDATE; > + * otherwise the next UPDATE will incorrectly use the one cre

Re: [HACKERS] UPDATE of partition key

On 1 January 2018 at 21:43, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 16 December 2017 at 03:09, Robert Haas <robertmh...@gmail.com> wrote: >> + /* >> + * UPDATEs set the transition capture map only when a new subplan >> + * is chosen. But for INSERTs,

Re: [HACKERS] UPDATE of partition key

On 20 December 2017 at 11:52, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 14 December 2017 at 08:11, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: >> >> Regarding ExecSetupChildParentMap(), it seems to me that it could simply >&

Re: [HACKERS] UPDATE of partition key

Robert, for tracking purpose, below I have consolidated your review items on which we are yet to conclude. Let me know if you have more comments on the points which I made. -- 1. ExecUpdate() needs to revert back tcs_map value changed by ExecInsert() -- >> + /* >>

Re: [HACKERS] UPDATE of partition key

ed that set of mappings? If there are no transition tables in picture, we don't require per-leaf child-parent conversion. So, this would mean that the tuple conversion maps will be set up for all (say, 100) leaf partitions even if there are only, say, a couple of update plans. I feel this would unnecessarily increase the startup cost of update-partition-key operation. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: partitioning - changing a slot's descriptor is expensive

dropped in ExecCleanupTupleRouting(). And also then we won't require the new field proute->partition_tuple_slots_alloced. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Slotification of partition tuple conversion

gresql.org/message-id/e4f9d743-cd4b-efb0-7574-da21d86a7f36%40lab.ntt.co.jp -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company tup_convert.patch Description: Binary data Allocate-dedicated-slots-of-partition-tuple_amitlan_rebased.patch Description: Binary data

Re: partitioning - changing a slot's descriptor is expensive

[1] https://www.postgresql.org/message-id/CAJ3gD9fR0wRNeAE8VqffNTyONS_UfFPRpqxhnD9Q42vZB%2BJvpg%40mail.gmail.com -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Slotification of partition tuple conversion

ut putting ConvertTupleSlot in execPartition.c and exporting > it in execPartition.h, instead of tupconvert.c and tupconvert.h, resp.? I think the goal of ConvertTupleSlot() is to eventually replace do_convert_tuple() as well, so it would look more of a general conversion rather than specific for p

Re: partitioning - changing a slot's descriptor is expensive

On 20 August 2018 at 14:45, Amit Langote wrote: > Thanks for the review. > > On 2018/08/17 15:00, Amit Khandekar wrote: >> Thanks for the patch. I did some review of the patch (needs a rebase). >> Below are my comments. >> >> @@ -1936,12 +1936,11 @@ ExecPart

Re: Slotification of partition tuple conversion

On 17 August 2018 at 21:47, Amit Khandekar wrote: > Attached is a patch tup_convert.patch that does the conversion > directly using input and output tuple slots. This patch is to be > applied on an essential patch posted by Amit Langote in [1] that > arranges for dedicated per-par

Re: AtEOXact_ApplyLauncher() and subtransactions

On 17 July 2018 at 03:29, Robert Haas wrote: > On Mon, Jul 16, 2018 at 2:36 AM, Amit Khandekar > wrote: >> 0001 patch contains the main fix. In this patch I have used some >> naming conventions and some comments that you used in your patch, >> plus, I used your method

Re: AtEOXact_ApplyLauncher() and subtransactions

On Thu, 5 Jul 2018 at 3:37 PM, Amit Khandekar wrote: > > On 4 July 2018 at 00:27, Robert Haas wrote: > > On Tue, Jun 26, 2018 at 6:25 AM, Amit Khandekar > > wrote: > >> Added this into the July 2018 commitfest : > >> > >> https://commitfest.p

Re: TupleTableSlot abstraction

e slots in those patches can "own" a minimal > tuple. Let's add a patch after 0006 i.e. tuple table abstraction > patch. Will do. Ashutosh offlist has shared with me 0009-Rethink-ExecFetchSlotMinimalTuple.patch which contains the above separated changes. The attached tar inc

Re: Query is over 2x slower with jit=on

ive figures in the leader process. Comments ? -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company jit_instr_account_workers.patch Description: Binary data

Re: TupleTableSlot abstraction

On 28 August 2018 at 22:43, Ashutosh Bapat wrote: > On Fri, Aug 24, 2018 at 6:46 AM, Andres Freund wrote: >> >>> -/* >>> - * slot_getsysattr >>> - * This function fetches a system attribute of the slot's >>> current tuple. >>> - * Unlike slot_getattr, if the slot does not

Re: Query is over 2x slower with jit=on

On 10 September 2018 at 21:39, Andres Freund wrote: > Hi, > > On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: >> Attached is a patch that accumulates the per-worker jit counters into >> the leader process. > > Thanks! > > >> I think we better show per-

Re: AtEOXact_ApplyLauncher() and subtransactions

On 4 July 2018 at 00:27, Robert Haas wrote: > On Tue, Jun 26, 2018 at 6:25 AM, Amit Khandekar > wrote: >> Added this into the July 2018 commitfest : >> >> https://commitfest.postgresql.org/18/1696/ > > It seems to me that it would probably be better to separate th

Re: Concurrency bug in UPDATE of partition-key

> reason if DELETE didn't happen ..."), but I think it will be clear if >> we can add some comments atop function ExecDelete. I will send the >> updated patch shortly. >> > > Attached, please find an updated patch based on comments by Alvaro. > See, if this looks okay to you guys. Thanks for the patch. It looks good to me. -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

e() finds that the row has been updated by another transaction. We should send back this information from ExecDelete() (I think tupleid parameter gets updated in this case), and then in ExecUpdate() we should goto lreplace, so that the the row is fetched back similar to how it happens when heap_update() knows that the tuple was updated. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 8 March 2018 at 12:34, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Mar 8, 2018 at 11:57 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 8 March 2018 at 09:15, Pavan Deolasee <pavan.deola...@gmail.com> wrote: >>> For example, with you

Re: Concurrency bug in UPDATE of partition-key

On 8 March 2018 at 16:55, Amit Khandekar <amitdkhan...@gmail.com> wrote: > The attached WIP patch is how the fix is turning out to be. > ExecDelete() passes back the epqslot returned by EvalPlanQual(). > ExecUpdate() uses this re-fetched tuple to re-process the row, just >

Hash join in SELECT target list expression keeps consuming memory

nd more memory, although to a lesser extent. But this is a different thing, and is already a known/expected behaviour : https://www.postgresql.org/message-id/29613.1476969807%40sss.pgh.pa.us -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Hash join in SELECT target list expression keeps consuming memory

On 17 March 2018 at 00:47, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Khandekar <amitdkhan...@gmail.com> writes: >> If the SELECT target list expression is a join subquery, and if the >> subquery does a hash join, then the query keeps on consuming more and >> m

Re: parallel append vs. simple UNION ALL

ilege(oid, 'USAGE'::text)) -> Hash -> Seq Scan on pg_authid u In grouping_planner() where partial paths are generated for final_rel, we can skip non-parallel-safe paths. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: partitioning - changing a slot's descriptor is expensive

it does not make sense to create as many slots, if at all we go by this approach. Suppose the partitioned table is the only one having different tuple descriptor, and rest of the partitions have same tuple descriptor. In that case, keep track of unique descriptors, and allocate a slot per unique descriptor. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

On 20 June 2018 at 14:28, Amit Khandekar wrote: > On 20 June 2018 at 14:24, Amit Kapila wrote: >> On Mon, Jun 18, 2018 at 3:11 PM, Amit Khandekar >> wrote: >>> On 16 June 2018 at 10:44, Amit Kapila wrote: >>>> On Thu, Jun 14, 2018 at 10:05 PM, Tom Lane wr

Re: TupleTableSlot abstraction

On Thu, 4 Oct 2018 at 22:59, Amit Khandekar wrote: > > I have only done the below two changes yet. After doing that and > rebasing with latest master, in the regression I got crashes, and I > suspect the reason being that I have used Virtual tuple slot for the > d

Re: TupleTableSlot abstraction

former lives in generic code, the latter is in ClearTuple. > > > I think the purpose of keeping this *before* clearing the tuple might > > be because the clear() might have already cleared some handles that > > release() might need. > > It's just plainly wrong to call it this way round. Ok. > > > > I went ahead and did these changes, but for now, I haven't replaced > > ExecFetchSlotTuple() with ExecFetchSlotHeapTuple(). Instead, I > > retained ExecFetchSlotTuple() to be called for heap tuples, and added > > a new ExecFetchGenericSlotTuple() to be used with shouldFree. I don't > > like these names, but until we have concluded, I don't want to go > > ahead and replace all the numerous ExecFetchSlotTuple() calls with > > ExecFetchSlotHeapTuple(). > > Why not? I haven't gone ahead because I wanted to know if you are ok with the names. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: TupleTableSlot abstraction

On Tue, 9 Oct 2018 at 20:46, Amit Khandekar wrote: > There is still one more regression test failure in polygon.sql which I > am yet to analyze. Below is a narrowed down testcase which reproduces the failure in polygon.sql : create table tab (n int, dist int, id integer); insert into tab

Re: TupleTableSlot abstraction

the patches (v12) to give you an idea of how I have handled the below two items. On Wed, 26 Sep 2018 at 05:09, Andres Freund wrote: > > On 2018-09-04 18:35:34 +0530, Amit Khandekar wrote: > > The attached v11 tar has the above set of changes. > > - I've pushed 0003 - although that co

Re: TupleTableSlot abstraction

> > After the slotification of partition tuple conversion, the input slot > is a virtual tuple, and the above code seems to result in some > corruption which I have not finished analyzing. It only happens for > INSERT ON CONFLICT case with partitions. In ExecInsert() and ExecUpdate(), wh

Re: Slotification of partition tuple conversion

On Wed, 26 Sep 2018 at 03:33, Andres Freund wrote: > > Hi Amit, > > Could you rebase this patch, it doesn't apply anymore. Thanks for informing. Attached are both mine and Amit Langote's patch rebased and attached ... -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postg

Re: TupleTableSlot abstraction

On Wed, 26 Sep 2018 at 05:15, Andres Freund wrote: > > Hi, > > On 2018-09-04 18:35:34 +0530, Amit Khandekar wrote: > > Subject: [PATCH 05/14] Use tts_flags instead of previous bool members > > > > Pack the boolean members in TupleTableSlot into a 16 bit tts_fl

Re: Query is over 2x slower with jit=on

On Tue, 25 Sep 2018 at 14:17, Andres Freund wrote: > > On 2018-09-18 10:03:02 +0530, Amit Khandekar wrote: > > Attached v3 patch that does the above change. > > Attached is a revised version of that patch. I've changed quite a few > things: > - I've reverted the split

Re: Pluggable Storage - Andres's take

On Fri, 18 Jan 2019 at 10:13, Amit Khandekar wrote: > On Tue, 15 Jan 2019 at 17:58, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Also I guess another attached patch should address the psql part, namely > > displaying a table access method with \d+ and possibility to hi

Re: Pluggable Storage - Andres's take

ryEx() with those extra parameters which are not needed in usual cases. E.g. we can have tablespace, tableam, dumpFn and dumpArg as those extra arguments of ArchiveEntryEx(), because most of the places these are passed as NULL. All future arguments would go in ArchiveEntryEx(). Comments ? -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Pluggable Storage - Andres's take

On Sun, 20 Jan 2019 at 22:46, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Fri, Jan 18, 2019 at 11:22 AM Amit Khandekar > > wrote: > > > > --- a/src/test/regress/expected/copy2.out > > +++ b/src/test/regress/expected/copy2.out > > @@ -1,

Re: Pluggable Storage - Andres's take

On Tue, 22 Jan 2019 at 15:29, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Mon, Jan 21, 2019 at 9:33 AM Amit Khandekar > > wrote: > > > > Regression tests that use \d+ to show the table details might > > not be interested specifically in table access me

Re: Pluggable Storage - Andres's take

On Tue, 15 Jan 2019 at 12:27, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Mon, Jan 14, 2019 at 2:07 PM Amit Khandekar > > wrote: > > > > createPQExpBuffer() should be moved after the below statement, so that > > it does not leak memory >

Re: ArchiveEntry optional arguments refactoring

ArchiveEntry( &(TocEntry){.tablespace = 3, .dumpFn = somefunc, ...}); -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company

Re: Pluggable Storage - Andres's take

On Tue, 15 Jan 2019 at 17:58, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Tue, Jan 15, 2019 at 10:52 AM Amit Khandekar > > wrote: > > > > Need to bump K_VERS_MINOR as well. > > I've bumped it up, but somehow this change escaped the previous

Trigger tuple slotification (extracted from pluggable storage patch)

(0001-Populate-slot-tts_tid-wherever-tuple-t_self-changes.patch), I have just added this field in the TupleTableSlot, and populated slot->tts_tid wherever tuple->t_self changes. [1] https://commitfest.postgresql.org/14/1283/ -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgre

Re: TupleTableSlot abstraction

On Wed, 14 Nov 2018 at 05:00, Andres Freund wrote: > After this, I hope Amit Khandekar will rebase a patch he's sent me > internally that converts triggers to use slots. I'll work on rebasing > the pluggable storage patch ontop of this. Shared this patch in a separate mail threa

Re: pgsql: Remove WITH OIDS support, change oid catalog column visibility.

ok into that next week. Wanna get my > head out of pluggable storage first... > > Greetings, > > Andres Freund > -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company errmsg_default_with_oids.patch Description: Binary data

Re: Displaying and dumping of table access methods

> > > > > For pg_dump, track and set the default_table_access_method setting > > > throughout the dump (similar to how default_with_oids was handled, I > > > believe). > > > > Yea, that's similar to that, and I think that makes sense. > > Yes, sounds like a

Re: Displaying and dumping of table access methods

On Fri, 11 Jan 2019 at 14:47, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Fri, Jan 11, 2019 at 6:02 AM Amit Khandekar > > wrote: > > > > > Yes, sounds like a reasonable approach, I can proceed with it. > > > > Dmitry, I believe you have

Re: Pluggable Storage - Andres's take

Thanks for the patch updates. A few comments so far from me : +static void _selectTableAccessMethod(ArchiveHandle *AH, const char *tablespace); tablespace => tableam +_selectTableAccessMethod(ArchiveHandle *AH, const char *tableam) +{ + PQExpBuffer cmd = createPQExpBuffer();

Re: Slotification of partition tuple conversion

On 3 September 2018 at 12:14, Amit Langote wrote: > Hi Amit, > > Thanks for the updated patch and sorry I couldn't reply sooner. > > On 2018/08/21 16:18, Amit Khandekar wrote: >> On 21 August 2018 at 08:12, Amit Langote >> wrote: >>> Here are some

Re: Query is over 2x slower with jit=on

On 11 September 2018 at 14:50, Amit Khandekar wrote: > On 10 September 2018 at 21:39, Andres Freund wrote: >> Hi, >> >> On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: >>> Attached is a patch that accumulates the per-worker jit counters into >>> the le

Re: Query is over 2x slower with jit=on

On 14 September 2018 at 16:48, Amit Khandekar wrote: > On 11 September 2018 at 14:50, Amit Khandekar wrote: >> On 10 September 2018 at 21:39, Andres Freund wrote: >>>> /* >>>> + * Add up the workers' JIT instrumentation from dynamic shared me

Re: Query is over 2x slower with jit=on

On 18 September 2018 at 03:20, Tom Lane wrote: > Amit Khandekar writes: >>>>> I think we better show per-worker jit info also. > > Just to throw a contrarian opinion into this: I find the current EXPLAIN > output for JIT to be insanely verbose already. One opt

Re: Minimal logical decoding on standbys

On Thu, 14 Mar 2019 at 15:00, Amit Khandekar wrote: > I managed to get a recovery conflict by : > 1. Setting hot_standby_feedback to off > 2. Creating a logical replication slot on standby > 3. Creating a table on master, and insert some data. > 2. Running : VACUUM FULL; > &g

Re: Minimal logical decoding on standbys

On Tue, 2 Apr 2019 at 21:34, Andres Freund wrote: > > Hi, > > On 2019-04-02 15:26:52 +0530, Amit Khandekar wrote: > > On Thu, 14 Mar 2019 at 15:00, Amit Khandekar wrote: > > > I managed to get a recovery conflict by : > > > 1. Setting hot_standby_feedbac

Re: Minimal logical decoding on standbys

On Wed, 3 Apr 2019 at 19:57, Amit Khandekar wrote: > Oops, it was my own change that caused the hang. Sorry for the noise. > After using wal_debug, found out that after replaying the LOCK records > for the catalog pg_auth, it was not releasing it because it had > actual

Re: Pluggable Storage - Andres's take

On Sat, 23 Feb 2019 at 01:22, Robert Haas wrote: > > On Fri, Feb 22, 2019 at 11:19 AM Amit Khandekar > wrote: > > Thanks for the review. Attached v2. > > Thanks. I took this, combined it with Andres's > v12-0040-WIP-Move-xid-horizon-computation-for-page-level-.pat

Re: Minimal logical decoding on standbys

estcases verify pg_controldata's oldestCatalogXmin values, which are now not present with Andres's patch; so I removed tracking of oldestCatalogXmin. [1] https://www.postgresql.org/message-id/CAMsr+YEVmBJ=dyLw=+kTihmUnGy5_EW4Mig5T0maieg_Zu=x...@mail.gmail.com Thanks -Amit Khandekar 0001-L

Re: Pluggable Storage - Andres's take

On Thu, 21 Feb 2019 at 04:17, Robert Haas wrote: > > On Fri, Feb 8, 2019 at 5:18 AM Amit Khandekar wrote: > > In the attached v1 patch, the prefetch_distance is calculated as > > effective_io_concurrency + 10. Also it has some cosmetic changes. > > I did a little br

Re: Pluggable Storage - Andres's take

On Thu, 21 Feb 2019 at 18:06, Robert Haas wrote: > > On Thu, Feb 21, 2019 at 6:44 AM Amit Khandekar wrote: > > Ok, so something like XidHorizonPrefetchState ? On similar lines, does > > prefetch_buffer() function name sound too generic as well ? > > Yeah, that s

Re: Minimal logical decoding on standbys

On Fri, 8 Mar 2019 at 20:59, Amit Khandekar wrote: > > On Mon, 4 Mar 2019 at 14:09, Amit Khandekar wrote: > > > > On Fri, 14 Dec 2018 at 06:25, Andres Freund wrote: > > > I've a prototype attached, but let's discuss the details in a separate > > > t

  1   2   3   >