On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila wrote:
> On Tue, Jun 4, 2024 at 7:40 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jun 4, 2024 at 4:27 PM Amit Kapila
> wrote:
> >>
> >>
> >> 3. Replicate published sequences via walsender at the time
Remote SQL: SELECT c3 FROM "S 1"."T 1" WHERE
(("C 1" > 10)) AND ((date(c5) = '1970-01-17'::date))
-(14 rows)
+ Relations: (public.ft1 t1) SEMI JOIN (public.ft2 t2)
+ Remote SQL: SELECT r1."C 1", r1.c2, r1.c3, r1.c4, r1.c5, r1.c6,
r1.c7, r1.c8 FROM "S 1"."T 1" r1 WHERE ((r1."C 1" < 20)) AND (EXISTS
(SELECT NULL FROM "S 1"."T 1" r3 WHERE ((r3."C 1" > 10)) AND
((date(r3.c5) = '1970-01-17'::date)) AND ((r1.c3 = r3.c3 ORDER BY
r1."C 1" ASC NULLS LAST
+(4 rows)
date_in | s |1 | [0:0]={cstring}
date_in which will be used to cast a test to date is not immutable. So
the query should't be pushed down. May not be a problem with your
patch. Can you please check?
--
Best Wishes,
Ashutosh Bapat
lication. A useful effect of this is to reduce WAL retention by
moving restart_lsn based on the latest confirmed_flush_lsn.
--
Best Wishes,
Ashutosh Bapat
On Thu, Sep 8, 2022 at 8:32 PM Ashutosh Sharma wrote:
>
> On Thu, Sep 8, 2022 at 6:23 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Sep 8, 2022 at 4:14 PM Ashutosh Sharma
> > wrote:
> > >
> > > Hi All,
> > >
> > > The logically decode
On Mon, Sep 19, 2022 at 1:43 PM Ashutosh Sharma wrote:
>
> On Fri, Sep 9, 2022 at 5:36 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Sep 8, 2022 at 8:32 PM Ashutosh Sharma
> > wrote:
> > >
> > > On Thu, Sep 8, 2022 at 6:23 PM Ashutosh Bapat
> >
On Mon, Sep 19, 2022 at 8:09 PM Ashutosh Sharma wrote:
>
> On Mon, Sep 19, 2022 at 5:24 PM Ashutosh Bapat
> wrote:
> >
> > On Mon, Sep 19, 2022 at 1:43 PM Ashutosh Sharma
> > wrote:
> > >
> > > On Fri, Sep 9, 2022 at 5:36 PM Ashutosh Bapat
> >
ally and start replicating the
changes. Users may not be able to intercept the replication activity
to add the associated sequences are also addedto the publication.
--
Best Wishes,
Ashutosh Bapat
using threads instead of parallel
workers e.g. for parallel vacuum, parallel query and so on while
leaving the processes for connections and leaders. that itself might
take significant time. Based on that experience move to a completely
threaded model. Based on my experience with other similar products, I
think we will settle on a multi-process multi-thread model.
--
Best Wishes,
Ashutosh Bapat
On Tue, Jun 13, 2023 at 11:01 PM Tomas Vondra
wrote:
>
> On 5/18/23 16:23, Ashutosh Bapat wrote:
> > Hi,
> > Sorry for jumping late in this thread.
> >
> > I started experimenting with the functionality. Maybe something that
> > was already discussed ear
:48 PM Ashutosh Bapat
wrote:
>
> On Tue, Jun 13, 2023 at 11:01 PM Tomas Vondra
> wrote:
> >
> > On 5/18/23 16:23, Ashutosh Bapat wrote:
> > > Hi,
> > > Sorry for jumping late in this thread.
> > >
> > > I started experimenting with the functi
e_changes = true;
But pg_decode_message() doesn't call pg_output_begin(). If a WAL
message is the first change in the transaction, it won't have a BEGIN
before it. That looks like a bug. Why is pg_decode_message()
exception?
--
Best Wishes,
Ashutosh Bapat
pg_logical_slot_get_changes_guts(), it looks like an argument can never be
NULL. But I see we have checks for NULL values of other arguments so it's ok to
keep a NULL check here.
I will look at 0004 next.
--
Best Wishes,
Ashutosh Bapat
On Mon, Jun 26, 2023 at 8:35 PM Tomas Vondra
wrote:
>
>
>
> On 6/26/23 15:18, Ashutosh Bapat wrote:
> > This is review of 0003 patch. Overall the patch looks good and helps
> > understand the decoding logic better.
> >
> > +
pg_output_begin() automatically takes care of these
conditions.
Otherwise the patches look good to me.
--
Best Wishes,
Ashutosh Bapat
suppress the error for which we are building
context or details. That's not useful. I think instead
logicalrep_message_type() should return "unknown" when it encounters
an unknown message type and let the original error message be thrown
as is.
--
Best Wishes,
Ashutosh Bapat
; case
defeats that purpose. I think we should just return "???" from outside
switch block.
--
Best Wishes,
Ashutosh Bapat
On Mon, Jul 3, 2023 at 6:52 PM Ashutosh Bapat
wrote:
>
> Thanks Euler for the patch.
>
> On Mon, Jul 3, 2023 at 6:32 PM Euler Taveira wrote:
> >
> > Masahiko, since abc0910e2e0 is your patch maybe you want to take a look at
> > it.
> >
>
> A cou
On Mon, Jun 26, 2023 at 8:35 PM Tomas Vondra
wrote:
> On 6/26/23 15:18, Ashutosh Bapat wrote:
> > I will look at 0004 next.
> >
>
> OK
0004- is quite large. I think if we split this into two or even three
1. publication and
subscription catalog handling 2. built-in replica
hat we need to do something so that a new call to
pg_output_begin() automatically takes care of the conditions under
which it should be called. Otherwise, we will introduce a similar
problem in some other place in future.
--
Best Wishes,
Ashutosh Bapat
t
apply_error_callback_arg.command = 0 before calling ereport in the
default case of apply_dispatch().
apply_error_callback() will just return without providing a context.
If we need a context and have all the other necessary fields, we can
improve apply_error_callback() to provide context when
apply_error_callback_arg.command = 0 .
--
Best Wishes,
Ashutosh Bapat
YPvmA%40mail.gmail.com
[6] https://www.postgresql.org/docs/current/storage-page-layout.html
--
Best Wishes,
Ashutosh Bapat
it's easy for users to setup them consistently.
GetPublicationRelations can be tweaked a bit to return just tables or sequences.
That along with publication's all sequences flag should tell us whether
publication publishes any sequences or not.
That ends my first round of reviews.
--
Best Wishes,
Ashutosh Bapat
Paquier wrote:
> > > On Tue, Aug 20, 2024 at 11:10:46AM +0530, Ashutosh Bapat wrote:
> > > > Since these are all related changes, doing them at once might make it
> > > > faster. You may use multiple commits (one for each change)
> > >
> > > Doing m
te for each aggregate
function - the notions of which are intuitive but they need to be
standardized. Of course, going this way means that it will take longer
for the feature to be available but it won't look like a kludge at
least.
--
Best Wishes,
Ashutosh Bapat
> t
>> (1 row)
>> 02b65000-082e5000 rw-p 00:00 0
>> [heap]
>> Size: 89600 kB
>> KernelPageSize:4 kB
>> MMUPageSize: 4 kB
>> Rss:4888 kB
>> Pss: 4
Hi Jacob,
On Wed, Aug 14, 2024 at 6:19 PM Jacob Champion
wrote:
>
> On Tue, Aug 13, 2024 at 9:07 PM Ashutosh Bapat
> wrote:
> > > I'm not entirely sure what you mean? src/test should work fine,
> > > anything lower than that (say src/test/ssl) does not.
> &
- TPS, latency etc. with and without
this function invoked during a benchmark run?
--
Best Wishes,
Ashutosh Bapat
On Sat, Aug 24, 2024 at 8:12 AM shawn wang wrote:
>
> Hi Ashutosh, thank you for your response.
> Firstly, the purpose of caching memory in malloc is for performance, so when
On Wed, Aug 28, 2024 at 5:26 PM Ashutosh Bapat
wrote:
>
> On Fri, Aug 23, 2024 at 9:55 PM Jacob Champion
> wrote:
> >
> > On Fri, Aug 23, 2024 at 5:59 AM Ashutosh Bapat
> > wrote:
> > > If I run
> > > export PG_TEST_EXTRA=xid_wraparound; ./configur
d $XID_MODULE_DIR && make check && cd
> $PGDir'
>
You are right. Jacob did point that out, but I didn't fix all the
places back then. Here's updated script.
--
Best Wishes,
Ashutosh Bapat
test_pg_test_extra.sh
Description: application/shellscript
On Wed, Sep 4, 2024 at 11:34 AM David G. Johnston
wrote:
>
>
> Agree on sticking with “The time…”
>
> Thus I suggest either:
>
> The time when the slot became inactive.
+1. Definitely removes confusion caused by "since" and keeps The time
as subject.
--
Best Wishes,
Ashutosh Bapat
t some of the) regression caused by 0002 comes from larger
structure. Why would that happen?
>
> Given the performance now seems improved in all cases, I plan on
> pushing this change as a single commit.
>
Agreed. I will review the code in detail by next week.
--
Best Wishes,
Ashutosh Bapat
ame(); tuplestore_largest_storage_type_name()
seems mouthful and yet not doing justice to the functionality. It
might be better to just have one funciton tuplestore_maxspace_used()
which returns both the maximum space used as well as the storage type
when maximum space was used.
The comments need a bit of grammar fixes, but that can be done when
finalizing the patches.
--
Best Wishes,
Ashutosh Bapat
On Fri, Sep 6, 2024 at 7:21 PM David Rowley wrote:
>
> On Fri, 6 Sept 2024 at 19:08, Ashutosh Bapat
> wrote:
> > The changes look better. A nitpick though. With their definitions
> > changed, I think it's better to change the names of the functions
> > since thei
On Fri, Jul 12, 2024 at 10:42 AM Ashutosh Bapat
wrote:
>
> I have merged the two patches now.
>
894be11adfa60ad1ce5f74534cf5f04e66d51c30 changed the schema in which
objects in test genereated_stored.sql are created. Because of this the
new test added by the patch was failing. Fixed th
eRowAttrNumber 0
add good comments about usage near their definitions and use
appropriately in the code.
Example above would then turn into (notice ! in the condition)
/* Prevent them from altering an attribute not defined by user */
if (!ATTNUM_IS_USER_DEFINED(attnum) )
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("attribute \"%s\" is not a user-defined attribute",
colName)));
--
Best Wishes,
Ashutosh Bapat
the
tests (and don't skip them).
Anyway with the proposed change PG_TEST_EXTRA passed at configuration
time is used if it's not defined at run time as expected. I think the
patch looks good. Nothing to complain there.
[1]
https://www.postgresql.org/message-id/CAN55FZ1Tko2N=x4f6icgfhb7syjyo_app-9ebfct-uh6tei...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAOYmi+=6hnvhbfovsv6x2_dvdycudl4amnj7im15gafw__b...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
rgs.pg_test_extra
>
> I think your suggestion is better, done.
I didn't see the expected change. I was talking about something like attached.
Also
1. I have also made changes to the comment,
2. renamed the argument --pg_test_extra to --pg-test-extra using
convention similar to other arguments.
3. few other cosmetic changes.
Please review and incorporate those in the respective patches and
tests. Sorry for a single diff.
Once this is done, I think we can mark this CF entry as RFC.
--
Best Wishes,
Ashutosh Bapat
pg_test_extra.diffs
Description: Binary data
s good. Thanks for working on it.
>
> Thanks. Attached is the v4 patch. I am going push it if there's no
> objection.
>
> After this, I will work on remaining node types.
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Best Wishes,
Ashutosh Bapat
as RFC.
--
Best Wishes,
Ashutosh Bapat
From f345f5dbbd0324a1b7389e046caefecab4c357fc Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Fri, 13 Sep 2024 10:58:40 +0530
Subject: [PATCH 3/4] Improve comment about configuration time PG_TEST_EXTRA
The comment mentioned "not safe" an
i.e. once state->usedDisk is set to true, it
> never goes back to false. So the test case is not necessary.
> David, am I correct?
I understand that. I am requesting a testcase to test that same logic.
--
Best Wishes,
Ashutosh Bapat
s will do. Is there a way to force the larger partition to
be computed first? That way we definitely know that the last
computation was done when all the tuples in the tuplestore were in
memory.
--
Best Wishes,
Ashutosh Bapat
y will be added to the targetlist
as resjunk columns and thus form separate instances of subquery thus
adding more subplans.
--
Best Wishes,
Ashutosh Bapat
luding +Tristan Partin who knows meson better.
If you are willing to work on this further, please add it to the commitfest.
--
Best Wishes,
Ashutosh Bapat
le_partitionwise_* GUCs mention that
"Each of the partitionwise join or aggregation which performs
sorting/hashing may consume work_mem worth of memory increasing the
total memory consumed during query execution.
--
Best Wishes,
Ashutosh Bapat
On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
>
> On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat
> wrote:
> > If those GUCs are enabled, the planner consumes large amount of memory
> > and also takes longer irrespective of whether partitionwise plan is
> > used or
On Thu, Jul 18, 2024 at 4:24 PM David Rowley wrote:
>
> On Thu, 18 Jul 2024 at 22:28, Ashutosh Bapat
> wrote:
> >
> > On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
> > > hmm? please tell me what word other than "can" best describes
> > >
e
> .cirrus.tasks.yml file should be removed as they are useless now. I
> added that as a second patch.
I think this is useful and allows both make and meson to use the same
logic in cirrus.
--
Best Wishes,
Ashutosh Bapat
de test_env() but I do not
> know how.
>
I am not suggesting to override test_env['PG_TEST_EXTRA'] but set it
to the value after overriding if required. meson.build file seems to
allow some conditional variable setting. So I thought this would be
possible, haven't tried myself though.
--
Best Wishes,
Ashutosh Bapat
On Tue, Jul 23, 2024 at 2:05 PM Richard Guo wrote:
>
> On Wed, Jun 5, 2024 at 3:48 PM Ashutosh Bapat
> wrote:
> > This is different. But it needs a rebase. PFA rebased patch. The revised
> > commit message explains the change better.
>
> I looked through this patch
On Wed, Jul 24, 2024 at 9:42 AM Richard Guo wrote:
>
> On Wed, May 22, 2024 at 3:57 PM Ashutosh Bapat
> wrote:
> > I will create patches for the back-branches once the patch for master is in
> > a committable state.
>
> AFAIU, this patch prevents apply_scan
nnoying-named fields where you want to look at
> how different data is correlated or broken-down. Something along the
> lines of:
To me this looks like a feature that a data exploration tool may
implement instead of being part of the server. It would then provide
more statistics about each correlation/column set etc.
--
Best Wishes,
Ashutosh Bapat
> expression is a bit out of line. I do not see similar places within
> PostgreSQL,
> so it probably violates code style.
>
They it's written, it would make it hard for the translations. See [1]
which redirects to [2].
[1] https://www.postgresql.org/docs/current/error-style-guide.html
[2] https://www.postgresql.org/docs/current/nls-programmer.html#NLS-GUIDELINES
--
Best Wishes,
Ashutosh Bapat
>
> Pushed.
>
> Thanks
> Richard
--
Best Wishes,
Ashutosh Bapat
elOptInfo id and RelOptInfo itself and another
containing all the paths identified by id and RelOptInfo id. The path
linkages are stored as path ids. That's a minimum. We will need more
tables to store query, and other metadata. If we do so we can use SQL
to carry out investigations.
--
Best Wishes,
Ashutosh Bapat
generated on primary before it
> considers the standby is ready for becoming a subscriber". Now, on
> busy systems, this shouldn't be a problem but for idle systems, the
> time to detect end-of-stream can't be easily defined.
AFAIU, the server will emit running transactions WAL record at least
15 seconds. So the subscriber should not have to wait longer than 15
seconds. I understand that it would be a problem for tests, but will
it be a problem for end users? Sorry for repetition, if this has been
discussed.
--
Best Wishes,
Ashutosh Bapat
On Mon, Jul 29, 2024 at 10:37 AM David Rowley wrote:
>
> On Fri, 19 Jul 2024 at 17:24, Ashutosh Bapat
> wrote:
> > I am fine if we want to mention that the executor may consume a large
> > amount of memory when these GUCs are turned ON. Users may decide to
> > tur
On Tue, Jul 30, 2024 at 5:38 PM David Rowley wrote:
>
> On Tue, 30 Jul 2024 at 21:12, Ashutosh Bapat
> wrote:
> > Thanks. This looks better. Nitpick
> >
> > +child partitions. With this setting enabled, the number of
> > executor
> > +no
ble name has lockmode in it.
Case3, worth changing to lockmode1 and lockmode2.
--
Best Wishes,
Ashutosh Bapat
e are aiming a minimal set of features in the first version. I will
let Peter E. decide whether to consider this as minimal set feature or
not. The feature looks useful to me.
--
Best Wishes,
Ashutosh Bapat
me, it is not
required to be set at run time.
2. Runtime PG_TEST_EXTRA always overrides configure time PG_TEST_EXTRA.
--
Best Wishes,
Ashutosh Bapat
apply the initial
> pruning if that is cheaper.
This will be fine if the number of surviving partitions is only 1 (or
at most a couple), but in case the number of surviving partitions
after pruning are more than a handful, partitionwise join + runtime
partition pruning will be required.
> Of course we also need to fix
> apply_scanjoin_target_to_paths to not drop old paths of partitioned
> joinrels so that we can retain non-partitionwise-join paths if
> the cheapest path happens to be among them. This work is being
> discussed in [1].
Right.
--
Best Wishes,
Ashutosh Bapat
On Wed, Aug 14, 2024 at 2:24 AM Jacob Champion
wrote:
>
> On Fri, Aug 9, 2024 at 2:26 AM Ashutosh Bapat
> wrote:
> > Here are my observations with the patch applied
> > 1. If I run configure without setting PG_TEST_EXTRA, it won't run the
> > tests that require
I don't
remember exactly why we didn't add it. May be because of trouble with
translations.
--
Best Wishes,
Ashutosh Bapat
ch is something we're not going to be able
> to check for (at least not in anything like this way). If
> you wanted to move the ease-of-use goalposts materially,
> you should be looking for a way to do that.
I think this check should be delegated to an FDW validator.
--
Best Wishes,
Ashutosh Bapat
Sorry for the delay in my response.
On Wed, May 29, 2024 at 9:34 AM Ashutosh Bapat
wrote:
>
> Documenting some comments from todays' patch review session
I forgot to mention back then that both of the suggestions below came
from Tom Lane.
> 1. Instead of a nested hash table, it m
On Mon, Aug 19, 2024 at 6:43 PM Ashutosh Bapat
wrote:
>
> Sorry for the delay in my response.
>
> On Wed, May 29, 2024 at 9:34 AM Ashutosh Bapat
> wrote:
> >
> > Documenting some comments from todays' patch review session
>
> I forgot to mention back then t
On Mon, Aug 19, 2024 at 7:47 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Aug 19, 2024 at 04:11:31PM +0530, Ashutosh Bapat wrote:
> > On Wed, Aug 14, 2024 at 5:02 PM Bertrand Drouvot
> > wrote:
> > >
> > > Hi hackers,
> > >
> > > wh
On Tue, Aug 20, 2024 at 10:49 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Tue, Aug 20, 2024 at 09:26:59AM +0530, Ashutosh Bapat wrote:
> > On Mon, Aug 19, 2024 at 7:47 PM Bertrand Drouvot
> > wrote:
> > >
> > > Hi,
> > >
> > > On
Mar 19 11:55:38 2018 -0400
Generate a separate upper relation for each stage of setop planning.
Can we use that to fix this bug?
--
Best Wishes,
Ashutosh Bapat
k
>> factor could go up a bit with those so that we take a stronger
>> consideration for hash or merge joins instead.
>>
>
> I thought about these ideas too. And I am not alone.
>
> https://hal.archives-ouvertes.fr/hal-01316823/document
>
> Regards
>
> Pavel
>
>> Anyway, it's pretty much a large research subject which would take a
>> lot of work to iron out even just the design. It's likely not a
>> perfect idea, but I think it has a bit more merit that trying to
>> introduce lies to the cost modal to account for a single case where
>> there is a problem.
>>
>> David
>>
>> [1]
>> https://www.postgresql.org/message-id/20200529001602.eu7vuiouuuiclpgb%40development
>>
>>
--
Best Wishes,
Ashutosh Bapat
On Tue, 2 Jun 2020 at 03:13, David Rowley wrote:
>
>
> It does seem likely to me that hash tables would be a more efficient
> structure, but the gains might not be as big as you think. To perform
> a lookup in the table we need to hash the entire node to get the hash
> value, then perform at leas
uld we document
this kind of failure?
--
Best Wishes,
Ashutosh Bapat
On Wed, Jun 3, 2020 at 12:44 PM Amit Langote wrote:
>
> On Thu, May 28, 2020 at 11:08 PM Ashutosh Bapat
> wrote:
> > On Wed, May 27, 2020 at 6:51 PM Amit Langote
> > wrote:
> > > So in Rajkumar's example, the cursor is declared as:
> > >
> > &g
eptable?
>
> In the attachment there is a patch with the correction of a stupid error.
>
> --
> Andrey Lepikhov
> Postgres Professional
> https://postgrespro.com
> The Russian Postgres Company
--
Best Wishes,
Ashutosh Bapat
From 9c4e09bd03cb98b1f84c42c34ce7b76e0
On Mon, Jun 15, 2020 at 12:41 PM Peter Eisentraut
wrote:
>
> Adjacent to the discussion in [0] I wanted to document the factorial()
> function and expand the tests for that slightly with some edge cases.
>
> I noticed that the current implementation returns 1 for the factorial of
> all negative nu
On Tue, 16 Jun 2020 at 08:48, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-06-15 13:15, Ashutosh Bapat wrote:
> > Here are some comments
> > I see below in the .out but there's not corresponding SQL in .sql.
> > +SELEC
On Tue, 16 Jun 2020 at 11:45, Amit Langote wrote:
> On Fri, Jun 12, 2020 at 9:22 PM Ashutosh Bapat
> wrote:
> > On Wed, Jun 3, 2020 at 12:44 PM Amit Langote
> wrote:
> > > Are you saying that the planner should take into account the state of
> > > the cursor
me impact on
> the design of this patch based on what we decide for that work.
>
Since 2PC is at the heart of any distributed transaction system, the
impact will be low. Figuring all of that, without having basic 2PC,
will be very hard.
--
Best Wishes,
Ashutosh Bapat
sharding
case as well.
As you said, even for a data warehousing application, there is some
write in the form of loading/merging data. If that write happens
across multiple servers, we need atomic commit to be guaranteed. Some
of these applications can work even if global consistency and atomic
visibility is guaranteed eventually.
--
Best Wishes,
Ashutosh Bapat
ped enable_hash_join and cursed :); but that was before
autocomplete was available). But enable_partitionwiseaggregate does
not look much different from enable_abracadabra :). Looking from that
angle, enable_incremental_sort is better than enable_incrementalsort.
We could have named enable_indexonlyscan as enable_index_only_scan for
better readability.
--
Best Wishes,
Ashutosh Bapat
On Wed, 17 Jun 2020 at 11:54, Andrey V. Lepikhov
wrote:
> On 6/15/20 10:26 AM, Ashutosh Bapat wrote:
> > Thanks Andrey for the patch. I am glad that the patch has taken care
> > of some corner cases already but there exist still more.
> >
> > COPY command constructed d
Hi All,
ExecInitPartitionInfo() has code
536 /*
537 * Open partition indices. The user may have asked to check for
conflicts
538 * within this leaf partition and do "nothing" instead of throwing
an
539 * error. Be prepared in that case by initializing the index
information
rd.
--
Best Wishes,
Ashutosh
From 638e922bebd9ee4657e40daa63b61ccac4bd205c Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Thu, 25 Jun 2020 18:50:52 +0530
Subject: [PATCH] Assert if ExecOpenIndices() is called twice on same result
relation.
If ExecOpenIndices() is called more than once
just be modulated
by batching DML. I doubt that's related to this feature exclusively
and should be solved independent of this feature.
>
> I was thinking about adding a GUC to enable/disable the batching at some
> level (global, server, table, ...) but it seems like a bad match because
> the consistency expectations likely depend on a query. There should be a
> GUC to set the batch size, though (it's hardcoded to 100 for now).
>
Similar to fetch_size, it should foreign server, table level setting, IMO.
[1]
https://www.postgresql.org/message-id/flat/3d0909dc-3691-a576-208a-90986e55489f%40postgrespro.ru
--
Best Wishes,
Ashutosh Bapat
On Tue, 30 Jun 2020 at 08:47, Etsuro Fujita wrote:
> On Mon, Jun 29, 2020 at 7:52 PM Ashutosh Bapat
> wrote:
> > On Sun, Jun 28, 2020 at 8:40 PM Tomas Vondra
> > wrote:
>
> > > 3) What about the other DML operations (DELETE/UPDATE)?
> > >
> > >
On Tue, 30 Jun 2020 at 22:23, Tomas Vondra
wrote:
> >I didn't get this. We are executing an INSERT on the foreign server,
> >so we get the number of rows INSERTed from that server. We should just
> >add those up across batches. If there's a failure, it would abort the
> >transaction, local as wel
been marked bad by
the time you fire new query. If the problem exists probably we should
fix it anyway since the backend at the other end of the connection has
higher chances of being killed while the connection was sitting idle
in the cache.
--
Best Wishes,
Ashutosh Bapat
ot;
> with path - try to use
> the cached connection at the beginning of remote xact, upon receiving
> error from remote postgres
> server, instead of aborting the query, delete the cached entry, try to
> get a new connection, if it
> gets, cache it and use that for executing the query, query succeeds.
> */
This will work. Be cognizant of the fact that the same connection may
be used by multiple plan nodes.
--
Best Wishes,
Ashutosh Bapat
w expression
>is used in an index.
>That would need special processing for pg_upgrade.
Again, that dependency needs to be maintained as and when the columns
are added and dropped.
--
Best Wishes,
Ashutosh Bapat
hen kill it by
calling pg_terminate_backend() to kill the remote backend to automate
scenario of remote backend being killed.
>
> I would like to thank Ashutosh Bapat (ashutosh.bapat@gmail.com)
> for the suggestion to fix this and the review of my initial patch
> attached in
RE clauses using built-in operators and
> functions will be considered for execution on the remote server".
>
> Although it seems that it will be easier to start with aggregates,
> probably we should initially plan a more general solution? For example,
> check that all involved tables are filtered by partitioning key and push
> down the entire query if all of them target the same foreign server.
>
> Any thoughts?
I think adding just equality conditions on the partition key will be
enough. No need for any code change.
--
Best Wishes,
Ashutosh Bapat
be better
> > than calling PQConnect* always.
> >
>
> Thanks for the comment, it made life easier. Added the patch with the
> changes. Please take a look at the v3 patch and let me know if still
> something needs to be done.
>
> [1] -
> https://www.postgresql.org/message-id/763A0689-F189-459E-946F-F0EC4458980B%40hotmail.com
>
> With Regards,
> Bharath Rupireddy.
> EnterpriseDB: http://www.enterprisedb.com
--
Best Wishes,
Ashutosh Bapat
the postprocessing (see
> [1]), but that would be too late for the FDW to do the push-down work.
> I have no idea what to do about this issue.
Won't partitionwise aggregate push aggregate down to partition and
then from there to the foreign server through FDW? Something else must
be stopping it. May be whole-var expression?
--
Best Wishes,
Ashutosh Bapat
On Fri, Jul 17, 2020 at 10:00 PM Etsuro Fujita wrote:
>
> On Sat, Jul 18, 2020 at 12:44 AM Ashutosh Bapat
> wrote:
> > On Fri, Jul 17, 2020 at 8:24 PM Etsuro Fujita
> > wrote:
> > > On Fri, Jul 17, 2020 at 1:56 AM Alexey Kondratov
> > > wrote:
Thanks a lot Fujita-san. Thanks Dmitry, Rajkumar, Amul, Mark, Robert,
Antonin, Amit, Justin,Thomas and Tomas for all your help and review.
On Wed, 8 Apr 2020 at 07:07, Etsuro Fujita wrote:
> On Wed, Apr 8, 2020 at 2:24 AM Etsuro Fujita
> wrote:
> > On Wed, Apr 8, 2020 at 12:15 AM Tomas Vondra
>
Thanks Kuntal for the report. Let me know if this patch works for you.
On Wed, 8 Apr 2020 at 13:00, Kuntal Ghosh
wrote:
> Hi,
>
> On Wed, Apr 8, 2020 at 7:07 AM Etsuro Fujita
> wrote:
> >
> > Pushed after modifying some comments further, based on the suggestions
> > of Ashutosh.
> I'm getting t
On Wed, 8 Apr 2020 at 15:42, Etsuro Fujita wrote:
> Hi Kuntal,
>
> On Wed, Apr 8, 2020 at 4:30 PM Kuntal Ghosh
> wrote:
> > I'm getting the following warning during compilation.
> >
> > partbounds.c: In function ‘partition_bounds_merge’:
> > partbounds.c:1024:21: warning: unused variable ‘inner_
st answer file.
>
--
Best Wishes,
Ashutosh Bapat
tion looks more purposed for join, but it's not difficult
to convert it to be used for UNION as well. In that case those set of
functions will have many more callers. So, I will vote to keep that
assertion now that we have it there.
--
Best Wishes,
Ashutosh Bapat
to the current EC infrastructure. So we still have to look
> through restrictlist.
>
When I wrote that function and even today, EC didn't accommodate outer
join equality conditions. If we can somehow do that,
have_partkey_equi_join() can be completely eliminated.
--
Best Wishes,
Ashutosh Bapat
701 - 800 of 1359 matches
Mail list logo
