> 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
On Tue, Jul 02, 2024 at 03:44:01AM +, masahiro.ik...@nttdata.com wrote:
> Although I plan to support "Rows Removed by Non Key Filtered"(or "Skip Scan
> Filtered"),
> I'd like to know whether the current direction is good. One of my concerns is
> there might
> be a better way to exact quals fo
> > 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,
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
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 Thu, Jun 27, 2024 at 11:06 PM wrote:
> OK. I would like to understand more about your proposed patch. I
> have also registered as a reviewer in the commitfests entry.
Great!
> Although I haven't looked on your patch yet, if it's difficult to know
> how it can optimize during the planning phas
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)' with a qual
> > "WHERE b = 5" are identical to a qual e
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)' with a qual
> "WHERE b = 5" are identical to a qual explicitly written "WHERE a =
> any() AND b = 5".
Hmm, that's true
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 Thu, Jun 27, 2024 at 4:46 PM Jelte Fennema-Nio wrote:
> On Thu, 27 Jun 2024 at 22:02, Peter Geoghegan wrote:
> > It's also possible that we should just do something simple, like your
> > patch, even though technically it won't really be accurate in cases
> > where skip scan is used to good eff
On Thu, 27 Jun 2024 at 22:02, Peter Geoghegan wrote:
> It's also possible that we should just do something simple, like your
> patch, even though technically it won't really be accurate in cases
> where skip scan is used to good effect. Maybe showing the "default
> working assumption" about how th
On Fri, Jun 21, 2024 at 3:12 AM wrote:
> Regarding the multicolumn B-Tree Index, I'm considering
> if we can enhance the EXPLAIN output. There have been requests
> for this from our customer.
I agree that this is a real problem -- I'm not surprised to hear that
your customer asked about it.
In t
> 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
>>=# EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM test WHERE id1 = 1 AND id3 = 101;
>> QUERY PLAN
>>
>>
> +1 for the idea.
Thanks! I was interested in the test result that you shared.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
> 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
> > ---
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 condition _does_
On Mon, Jun 24, 2024 at 8:08 AM wrote:
> > 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 indica
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 condition _does_ require a visibility check, and
> delegates the check to the table
On Mon, 24 Jun 2024 at 11:58, Jelte Fennema-Nio wrote:
>
> +1 for the idea.
>
> On Mon, 24 Jun 2024 at 11:11, Matthias van de Meent
> wrote:
> > I think this is too easy to confuse with the pre-existing 'Filter'
> > condition, which you'll find on indexes with INCLUDE-d columns or
> > filters on
+1 for the idea.
On Mon, 24 Jun 2024 at 11:11, Matthias van de Meent
wrote:
> I think this is too easy to confuse with the pre-existing 'Filter'
> condition, which you'll find on indexes with INCLUDE-d columns or
> filters on non-index columns.
Why not combine them? And both call them Filter? In
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
> -
> > * 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
> 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
On Fri, 21 Jun 2024 07:12:25 +
wrote:
> * 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
On Fri, Jun 21, 2024 at 12:42 PM wrote:
> Hi,
>
>
>
> Regarding the multicolumn B-Tree Index, I'm considering
>
> if we can enhance the EXPLAIN output. There have been requests
>
> for this from our customer.
>
>
>
> As the document says, we need to use it carefully.
>
> > The exact rule is that
26 matches
Mail list logo
