>> While searching the definition of auxiliary processes, I noticed that
>> the description of the WAL summarizer is incorrect. Additionally, I
>> think it's better to add a description for the WAL writer similar to
>> other Auxiliary processes. What do you think?
>
> Good catch. Would you like to
> 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 boun
> > * Is this feature useful? Is there a possibility it will be accepted?
>
> I think adding such information to EXPLAIN outputs is useful because it will
> help users
> confirm the effect of a multicolumn index on a certain query and decide to
> whether
> leave, drop, or recreate the index, and
> On Mon, 24 Jun 2024 at 04:38, wrote:
> >
> > In my local PoC patch, I have modified the output as follows, what do you
> > think?
> >
> > =# EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM test WHERE id1 = 1 AND id2 =
> 101;
> >QUERY PLAN
> > ---
> +1 for the idea.
Thanks! I was interested in the test result that you shared.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
>>=# EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM test WHERE id1 = 1 AND id3 = 101;
>> QUERY PLAN
>>
>>
> On Mon, 24 Jun 2024 at 14:42, Jelte Fennema-Nio wrote:
> >
> > On Mon, 24 Jun 2024 at 13:02, Matthias van de Meent
> > wrote:
> > > It does not really behave similar: index scan keys (such as the
> > > id3=101 scankey) don't require visibility checks in the btree code,
> > > while the Filter co
Hi,
Thanks for working it! I'm interested in this feature, so I'd like to
participate in the
patch review. Though I've just started looking at the patch, I have two comments
about the v6 patch. (And I want to confirm the thread active.)
1) Unify the print format of leader and worker
In show_ti
Hi,
Thanks for working it! I'm interested in this feature, so I'd like to
participate
in the patch review. Though I've just started looking at the patch, I have two
comments about the v6 patch. (And I want to confirm the thread active.)
1) Unify the print format of leader and worker
In show_ti
On Thu, 27 Jun 2024 at 22:02, Peter Geoghegan wrote:
> Unfortunately, my patch will make the situation more complicated
> for your patch. I would like to resolve the tension between the
> two patches, but I'm not sure how to do that.
OK. I would like to understand more about your proposed patch.
On 2024-06-28 21:05, Matthias van de Meent wrote:
> On Fri, 28 Jun 2024 at 10:59, Jelte Fennema-Nio wrote:
>>
>> On Fri, 28 Jun 2024 at 00:41, Peter Geoghegan wrote:
>> > Typically, no, it won't be. But there's really no telling for sure.
>> > The access patterns for a composite index on '(a, b)'
On 2024-06-29 03:27, Peter Geoghegan wrote:
> On Thu, Jun 27, 2024 at 11:06 PM wrote:
>> Although I haven't looked on your patch yet, if it's difficult to know
>> how it can optimize during the planning phase, it's enough for me to just
>> show "Skip Scan Cond (or Non-Key Filter)". This is because
> > I think the better choice would be adding an IndexAmRoutine->amexplain
> > support function, which would get called in e.g. explain.c's
> > ExplainIndexScanDetails to populate a new "Index Scan Details" (name
> > to be bikeshed) subsection of explain plans. This would certainly be
> > possible,
Hi,
While I'm researching about [1], I found there are inconsistent EXPLAIN outputs.
Here is an example which shows " OPERATOR(pg_catalog.". Though it's not wrong,
I feel like there is no consistency in the output format.
-- A reproduce procedure
create temp table btree_bpchar (f1 text collate "C
Thanks for your comments.
Tom Lane writes:
> Tomas Vondra writes:
> > I honestly don't know if this is the correct solution. It seems to me
> > handling this at the EXPLAIN level might just mask the issue - it's
> > not clear to me why adding "indexqualorig" would remove the ambiguity
> > (if t
Hi,
Since I'd like to understand the skip scan to improve the EXPLAIN output
for multicolumn B-Tree Index[1], I began to try the skip scan with some
queries and look into the source code.
I have some feedback and comments.
(1)
At first, I was surprised to look at your benchmark result because t
Hi,
Thanks for working the feature. As a user, I find it useful, and I'd like to use
it in v18! Although I've just started start looking into it, I have a few
questions.
(1)
Is it better to make the order of output consistent? For example, even
though there are three clauses shown in the below
Hi,
When I read the following documentation related to the
"synchronized_standby_slots", I misunderstood that data loss would not occur in
the case of synchronous physical replication. However, this is incorrect (see
reproduce.txt).
> Note that in the case of asynchronous replication, there re
Thans for your responses.
> I think you see such a behavior because you have disabled
> 'synchronized_standby_slots'
> in your script (# disable "synchronized_standby_slots"). You need to enable
> that to
> avoid data loss. Considering that, I don't think your proposed text is an
> improvement.
> So, will it be okay if we just remove ".. without losing data" from the
> sentence? Will that
> avoid the confusion you have?
Yes. Additionally, it would be better to add notes about data consistency after
failover for example
Note that data consistency after failover can vary depending on the
> > > So, will it be okay if we just remove ".. without losing data" from
> > > the sentence? Will that avoid the confusion you have?
> > Yes. Additionally, it would be better to add notes about data
> > consistency after failover for example
> >
> > Note that data consistency after failover can va
> > > > > So, will it be okay if we just remove ".. without losing data"
> > > > > from the sentence? Will that avoid the confusion you have?
> > > > Yes. Additionally, it would be better to add notes about data
> > > > consistency after failover for example
> > > >
> > > > Note that data consisten
> Let me share my opinion on those questions ...
Thanks! I could understand the patch well thanks to your comments.
> On 7/12/24 12:09, masahiro.ik...@nttdata.com wrote:
> > Is it better to make the order of output consistent? For example, even
> > though there are three clauses shown in the be
> On 7/18/24 12:37, masahiro.ik...@nttdata.com wrote:
> >> Let me share my opinion on those questions ...
> > ...>
> >> For ndistinct, I think we don't show this because it doesn't go
> >> through clauselist_selectivity, which is the only thing I modified in the
> >> PoC.
> >> But I guess we might
> The CF bot is red for some time now, please provide a rebase.
Thanks. I have attached the rebased patch.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
v3-0001-Support-Non-Key-Filter-for-multicolumn-B-Tree-Ind.patch
Description: v3-0001-Support-Non-Key-Filter-for-multicolumn-B-Tree-Ind.pat
25 matches
Mail list logo
