passing both the
arguments is an error.
Also I don't think "Note that setup
# suite tests (at least tmp_install and initdb_cache tests) may need to be run
# before running these tests." is needed. This is true irrespective of
whether we specify TESTS or not.
--
Best Wishes,
Ashutosh Bapat
have to document it in meson. But if we
want to document it in meson, we should document it in make as well.
--
Best Wishes,
Ashutosh Bapat
to the function definition, the plan is
> (as expected) a simple function scan.
> But - to my surprise - auto explain in the logs shows unexpected plan with
> all nodes scanning partitions having row estimates = 1
>
> Is it expected behavior?
>
> —
> Michal
>
--
Best Wishes,
Ashutosh Bapat
On Wed, Sep 25, 2024 at 8:24 PM Nazir Bilal Yavuz wrote:
>
> Hi,
>
> Thanks for looking into this!
>
> On Wed, 25 Sept 2024 at 13:27, Ashutosh Bapat
> wrote:
> >
> > On Mon, Sep 23, 2024 at 2:16 PM Nazir Bilal Yavuz
> > wrote:
> > >
> >
vidual SQL tests using same
syntax e.g. `meson test regress:partition_join` that would make it
consistent with the way TAP tests are run. But we need to make sure
that the test later in the syntax would see the objects left behind by
prior tests. E.g. `meson test regress:test_setup
regress:partition_join` should see both tests passing. partition_join
uses some tables created by test_setup, so those need to be run
sequentially. Is that doable?
--
Best Wishes,
Ashutosh Bapat
On Thu, Sep 19, 2024 at 4:18 PM Andrei Lepikhov wrote:
>
> On 6/2/2024 13:51, Ashutosh Bapat wrote:
> > On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
> > wrote:
> >
> >>>
> >>> That looks pretty small considering the benefits. What do you think?
&
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
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
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
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
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
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
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
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
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
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
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
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
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, 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
- 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
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.
> &
> 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
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
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
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
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 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
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
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
I don't
remember exactly why we didn't add it. May be because of trouble with
translations.
--
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
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
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
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
ble name has lockmode in it.
Case3, worth changing to lockmode1 and lockmode2.
--
Best Wishes,
Ashutosh Bapat
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
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
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
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
>
> Pushed.
>
> Thanks
> Richard
--
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
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
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
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
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
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
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
> > >
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
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
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
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
On Fri, Jul 12, 2024 at 11:59 AM Ashutosh Bapat
wrote:
>
>
> Now that you are also seeing the slowdown with your earlier patch, I
> am wondering whether adding unlikely() by itself is a good
> optimization. There might be some other reason behind the perceived
> slowdown. How d
On Thu, Jul 11, 2024 at 5:39 PM David Rowley wrote:
>
> On Wed, 10 Jul 2024 at 02:42, Ashutosh Bapat
> wrote:
> > Observations
> > 1. The numbers corresponding to 10 and 100 partitions are higher when
> > patched. That might be just noise. I don't see an
On Tue, Jul 9, 2024 at 1:07 PM Michael Paquier wrote:
>
> On Mon, Jul 08, 2024 at 03:59:30PM +0530, Ashutosh Bapat wrote:
> > Before submitting the patch, I looked for all the places which mention
> > AdjustUpgrade or AdjustUpgrade.pm to find places where the new module needs
&
ensive. But if there are multiple places which do something like
this, we may want to create more function get_rel_* function which return
multiple properties in one function call. I see get_rel_namspace() and
get_rel_name() called together at many places.
--
Best Wishes,
Ashutosh Bapat
if configured that way.
--
Best Wishes,
Ashutosh Bapat
nces.
2. For 1M partitions it does make a difference. About 35% in my case.
Moreover the change seems to be making the execution times independent
of the number of partitions (more or less).
Combining this observation with the first one, It might be worth
looking at the execution times when there are many rows per partition
in case of a higher number of partitions.
--
Best Wishes,
Ashutosh Bapat
by show_*_info functions(). We might even convert it into a tuplestore
specific implementation hook after David's work.
--
Best Wishes,
Ashutosh Bapat
On Fri, Jul 5, 2024 at 10:59 AM Michael Paquier wrote:
> On Fri, Jun 28, 2024 at 06:00:07PM +0530, Ashutosh Bapat wrote:
> > Here's a description of patches and some notes
> > 0001
> > ---
> > 1. Per your suggestion the logic to handle dump output di
rent. The latter
is a unified representation of columns of joining relations different
from those columns and hence needs a new representation. That doesn't
seem to be the case with RangeTblEntry::groupexpr.
8. The change in process_sublinks_mutator() appears to be related to
the fact that GROUPING() may have subqueries which were not being
handled earlier. That change seems to be independent of the bug being
fixed here. Am I right? If yes, having those changes in a separate
patch will help.
--
Best Wishes,
Ashutosh Bapat
rt
Sort Key: t.a, t.b
-> HashAggregate
Hash Key: t.a, t.b
Hash Key: t.a
-> Values Scan on "*VALUES*" t
Filter: (a = b)
(8 rows)
I didn't get time to figure out the reason behind this, nor the history.
But I thought I would report it nonetheless.
--
Best Wishes,
Ashutosh Bapat
On Sat, Jun 29, 2024 at 2:12 PM Jelte Fennema-Nio
wrote:
> On Sat, 29 Jun 2024 at 01:13, Thomas Munro wrote:
> >
> > On Sat, Jun 29, 2024 at 1:10 AM Ashutosh Bapat
> > wrote:
> > > I need to sign in to github to add my review comments. So those who do
> not hav
On Wed, Jun 12, 2024 at 4:22 AM David Christensen
wrote:
> On Mon, Jun 10, 2024 at 8:15 AM Robert Haas wrote:
> >
> > On Mon, Jun 10, 2024 at 3:09 AM Ashutosh Bapat
> > wrote:
> > > This is just one instance of measurements. If I run the experiment
> multiple t
So those who do not
have a github account can not use it for review. But I don't think that can
be fixed. We need a way to know who left review comments.
There was some discussion at pgconf.dev about using gitlab instead of
github. How easy is it to use gitlab if we decide to go that way?
--
Best Wishes,
Ashutosh Bapat
On Wed, Jun 26, 2024 at 8:54 PM Tom Lane wrote:
> Ashutosh Bapat writes:
> > The usage help mentions exit code 2 specifically while describing --check
> > option but it doesn't mention exit code 1. Neither does the README. So I
> > don't think we need to docume
Sorry for delay, but here's next version of the patchset for review.
On Thu, Jun 6, 2024 at 5:07 AM Michael Paquier wrote:
> On Wed, Jun 05, 2024 at 05:09:58PM +0530, Ashutosh Bapat wrote:
> > Thanks for the suggestion. I didn't understand the dependency with the
> > b
't think we need to document exit code 3 anywhere. Please let me know if
you think otherwise.
--
Best Wishes,
Ashutosh Bapat
From 7a0f65a2367885eea0c9b7a4257e6faf758f58eb Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Wed, 26 Jun 2024 15:46:53 +0530
Subject: [PATCH 1/2] pgindent exi
de 3. I am
open to both.
[1] https://en.wikipedia.org/wiki/Exit_status
--
Best Wishes,
Ashutosh Bapat
From f43a90ead02637896e375144b015b971b5e86fce Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Wed, 26 Jun 2024 15:46:53 +0530
Subject: [PATCH 1/2] pgindent exit status on error
When pg_
h Index Cond. I am
not sure whether Index Filter is the right name, maybe Index Bound Cond:
But I don't know this area enough to make a final call.
About Rows Removed by Index Filter: it's good to provide a number when
ANALYZE is specified, but it will be also better to specify what was
estimated. We do that for (cost snd rows etc.) but doing that somewhere in
the plan output may not have a precedent. I think we should try that and
see what others think.
--
Best Wishes,
Ashutosh Bapat
er of solar days in a solar year?
> - 365, because we don't consider leap years?
> - 360, because we use the usual conversion of 1 month -> 30 days?
>
We will need to go back to first principles, I guess. Result of division is
quotient, which is how many times a divisor can be subtracted from
dividend, and remainder, which is the what remains after so many
subtractions. Since day to hours and month to days conversions are not
constants, interval/interval will result in an integer quotient and
interval remainder. That looks painful.
--
Best Wishes,
Ashutosh Bapat
.
>
> * Is "Index Bound Cond" the proper term?I also considered changing
>
> "Index Cond" to only show quals for the boundary condition and adding
>
> a new term "Index Filter".
>
> * Would it be better to add new interfaces to Index AM? Is there any case
>
> to output the EXPLAIN for each index context? At least, I think it's
> worth
>
> considering whether it's good for amcostestimate() to modify the
>
> IndexPath directly as the PoC patch does.
>
>
>
I am unable to decide whether reporting the bound quals is just enough to
decide the efficiency of index without knowing the difference in the number
of index tuples selectivity and heap tuple selectivity. The difference
seems to be a better indicator of index efficiency whereas the bound quals
will help debug the in-efficiency, if any.
Also, do we want to report bound quals even if they are the same as index
conditions or just when they are different?
--
Best Wishes,
Ashutosh Bapat
le from store using this slot
and then store it into ResultTupleSlot using its ttsops. Other types of
planstate nodes some times return the slot they get from their subplans as
is without going through ResultTupleSlot. You may want to do something like
that, if the result tuple contents are same as the tuple stored in
tuplestore
--
Best Wishes,
Ashutosh Bapat
On Thu, Jun 20, 2024 at 3:21 PM Amit Kapila wrote:
> On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila
> wrote:
> >>
> >> > I doubt that it would be that simple. The application will have to
> are from T1. Lastly, when T3 is applied, r1 will be from T3 and r2
> will be from T1. This is what you mentioned will happen after conflict
> resolution in the above example.
>
>
You are right. It won't affect the consistency. The contents of transaction
on each node might vary after application depending upon the changes that
conflict resolver makes; but the end result will be the same.
--
Best Wishes,
Ashutosh Bapat
t to keep the template1
on primary and replica in sync. Replication slot associated with template1
would be useful there.
[1]
https://www.postgresql.org/docs/current/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS
--
Best Wishes,
Ashutosh Bapat
completely puts db transactions on hold. For this I want
> tables shouldnt get locked also the backup process should complete in less
> time.
>
These questions are appropriate for pgsql-general mailing list.
--
Best Wishes,
Ashutosh Bapat
;
> There are practical difficulties like maintaining the expected outputs for
such a large battery of tests. But maybe some external project could.
BTW, have you considered perl tests, isolation tests etc. Tests in regress/
do not cover many subsystems e.g. replication.
--
Best Wishes,
Ashutosh Bapat
n_schema. So, to summarize this at a high
> > level, here's is what I think can be done:
> >
> > 1) Include extension-specific details, possibly the extension OID, for
> > functions in pg_proc during function creation.
> >
>
> Alternatively, we could leverage the extension dependency information
> to determine whether the function is created by an extension or not.
>
>
That will be simpler. We do that sort of thing for identity sequences. So
there's a precedent to do that kind of stuff.
--
Best Wishes,
Ashutosh Bapat
On Sat, Jun 8, 2024 at 3:52 PM Amit Kapila wrote:
> On Fri, Jun 7, 2024 at 5:39 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Jun 6, 2024 at 5:16 PM Nisha Moond
> wrote:
> >>
> >> >
> >>
> >> Here are more use cases of the "earlies
statement.
> --
> Regards,
> ChangAo Chen
>
--
Best Wishes,
Ashutosh Bapat
On Thu, Jun 6, 2024 at 10:00 PM Robert Haas wrote:
> On Wed, Jun 5, 2024 at 3:48 AM Ashutosh Bapat
> wrote:
> > Here's planning time measurements.
> > num_joins | master (ms) | patched (ms) | change in planning time (ms) |
&g
ree
transactions. Would that introduce an inconsistency between r1 and r2?
--
Best Wishes,
Ashutosh Bapat
On Thu, Jun 6, 2024 at 9:22 AM Amit Kapila wrote:
> On Wed, Jun 5, 2024 at 6:01 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila
> wrote:
> >>
> >> How about periodically sending this information?
> >> >
> &g
On Wed, Jun 5, 2024 at 1:17 PM Ashutosh Bapat
wrote:
> Hi David,
> Thanks for looking into this.
>
> On Fri, May 31, 2024 at 2:19 AM David Christensen
> wrote:
>
>> Hello,
>>
>> I am looking through some outstanding CommitFest entries; I wonder if
>> th
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
On Tue, Jun 4, 2024 at 4:28 AM Michael Paquier wrote:
> On Fri, Apr 26, 2024 at 06:38:22PM +0530, Ashutosh Bapat wrote:
> > Some points for discussion:
> > 1. The test still hardcodes the diffs between two dumps. Haven't found a
> > better way to do it. I did conside
On Mon, Jun 3, 2024 at 10:04 PM Tristan Partin wrote:
> On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote:
> > "Tristan Partin" writes:
> > > On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote:
> > >> We talked this off-list at the conference.
s column statistics and this bug I
am fixing. Can you please elaborate?
> 3. I dislike, that this patch makes much harder to debug, why no
> partitionwise join is chosen.
>
Can you please elaborate more? How does my change make debugging harder?
--
Best Wishes,
Ashutosh Bapat
7;planning time' and p.variant = 'pwj'
order by p.vari
ant, num_joins;
[1]
https://www.postgresql.org/message-id/CAExHW5snUW7pD2RdtaBa1T_TqJYaY6W_YPVjWDrgSf33i-0uqA%40mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
setup.sql
Description: application/sql
queries.sql
Description: app
f the node.
>
> Any other ideas?
>
>
In case of primary crash the sequence won't get replicated. That is true
even with the previous approach in case walsender is shut down because of a
crash, but it is more serious with this approach. How about periodically
sending this information?
--
Best Wishes,
Ashutosh Bapat
ssing pg_regress --schedule argument and instead pass the list of
tests. Any idea how to do that?
--
Best Wishes,
Ashutosh Bapat
On Mon, Feb 19, 2024 at 5:17 AM Ashutosh Bapat
wrote:
> On Mon, Feb 19, 2024 at 4:35 AM Tomas Vondra
> wrote:
> >
> > Hi,
> >
> > After taking a look at the patch optimizing SpecialJoinInfo allocations,
> > I decided to take a quick look at this one too. I
ty for you. Am I right?
Plans with lower costs being slower is not new for optimizer.
Partitionwise join just adds another case.
>
> Maybe we can discuss that in person next week?
>
Sure.
>
> On 2024-05-22 07:57, Ashutosh Bapat wrote:
> >
> > The test was added by 6b
e
> tempted to introduce a missing_ok to this routine after looking at the
> callers in all the tree, as some of them want to fail still would not
> expect it, so that would reduce a bit the elog churn. That's a story
> for a different day, though.
> --
> Michael
>
--
Best Wishes,
Ashutosh Bapat
On Fri, May 24, 2024 at 12:16 PM Michael Paquier
wrote:
> On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
> > If we are looking for avoiding a segfault and get a message which helps
> > debugging, using get_attname and get_attnum might be better options.
> >
the function. There was some
discussion about setting a search path for a function at [1]. But the last
message there is non-conclusive. We may want to extend it to extensions
such that all the object references in a given extension are resolved using
extension specific search_path.
[1]
https://www.postgresql.org/message-id/2710f56add351a1ed553efb677408e51b060e67c.camel%40j-davis.com
--
Best Wishes,
Ashutosh Bapat
oesn't throw an error and returns
InvalidAttnum which won't return any valid identity sequence, and thus
return a NIL sequence list which is handled in that function already. Using
these two functions will avoid the clutter as well as segfault. If that's
acceptable, I will provide a patch.
--
Best Wishes,
Ashutosh Bapat
ase+OJ", but I cannot find the
> explanation of "OJ" or the "OJ" Acronyms.
>
>
> OJ is an outer join, AFAIU. OJ's have their own relids. If you are
wondering why not all joins - I think inner joins need not be tracked as
separated relations in parse tree, but OJ's need to be.
--
Best Wishes,
Ashutosh Bapat
have to invoke relation_open() with new relid, in order to use rel in the
error message. I don't think all that is worth it, unless we find a
scenario when SearchSysCacheAttName() returns NULL.
--
Best Wishes,
Ashutosh Bapat
1 - 100 of 1007 matches
Mail list logo
