t step I would be very happy to
propose a patch as well.
Best regards,
Shayon Mukherjee
with adding a new flag. There's even a free
> padding byte to put this flag in after indisreplident, so we don't
> have to worry about using more memory.
>
> David
>
--
Kind Regards,
Shayon Mukherjee
Hello,
Thank you for the detailed information and feedback David. Comments inline.
P.S Re-sending it to the mailing list, because I accidentally didn't select
reply-all on the last reply.
On Mon, Sep 9, 2024 at 6:16 PM David Rowley wrote:
> On Tue, 10 Sept 2024 at 09:39, Shayon M
> On Oct 7, 2024, at 4:52 PM, Robert Haas wrote:
>
> On Mon, Sep 23, 2024 at 11:14 AM Peter Eisentraut
> wrote:
>> I think a better approach would be to make the list of disabled indexes
>> a GUC setting, which would then internally have an effect similar to
>> enable_indexscan, meaning it w
On Oct 15, 2024, at 7:25 PM, David Rowley wrote:On Wed, 16 Oct 2024 at 03:40, Robert Haas wrote:On Sat, Oct 12, 2024 at 5:56 AM Shayon Mukherjee wrote:Thank you for sharing this Robert. I like the idea behind "allowing extensions to control planner behavior” overall and I think it does
> On Oct 16, 2024, at 2:15 PM, Shayon Mukherjee wrote:
>
>
>> On Oct 16, 2024, at 12:19 PM, Shayon Mukherjee wrote:
>>
>> - ALTER INDEX ... ENABLE/DISABLE performs an in-place update of the pg_index
>> catalog to protect against indcheckxmin [2] (older u
On Oct 16, 2024, at 12:19 PM, Shayon Mukherjee wrote:- ALTER INDEX ... ENABLE/DISABLE performs an in-place update of the pg_index catalog to protect against indcheckxmin [2] (older unrelated thread).Performing the in place update of the pg_index row from ATExecEnableDisableIndex using
On Oct 16, 2024, at 6:01 PM, Shayon Mukherjee wrote:
I'll take some time to think this through and familiarize myself with the
new systable_inplace_update_begin. In the meantime, aside from the in-place
updates on pg_index, I would love to learn any first impressions or
feedback on the
On Sat, Oct 5, 2024 at 1:37 AM David Rowley wrote:
> On Sat, 5 Oct 2024 at 03:03, Robert Haas wrote:
> > I tend to gravitate
> > toward displaying things exactly as they exist internally because I've
> > had so many bad experiences with having to try to reverse-engineer the
> > value stored inte
Hi David,
Answered below
> On Oct 9, 2024, at 9:19 AM, David Rowley wrote:
>
> On Wed, 9 Oct 2024 at 20:07, Shayon Mukherjee wrote:
>> [thinking…] Unless - we try to do support both a GUC and the ALTER INDEX
>> ENABLE/DISABLE grammar + isdisabled attribute on pg_index?
> On Oct 9, 2024, at 1:41 PM, Robert Haas wrote:
>
> On Wed, Oct 9, 2024 at 4:19 AM David Rowley <mailto:dgrowle...@gmail.com>> wrote:
>> On Wed, 9 Oct 2024 at 20:07, Shayon Mukherjee wrote:
>>> [thinking…] Unless - we try to do support both a GUC and th
NVISIBLE]".
>
> David
>
> [1]
> https://www.postgresql.org/message-id/20180618215635.m5vrnxdxhxytvmcm%40alap3.anarazel.de
> [2]
> https://www.postgresql.org/message-id/CAKJS1f_L7y_BTGESp5Qd6BSRHXP0mj3x9O9C_U27GU478UwpBw%40mail.gmail.com
>
--
Kind Regards,
Shayon Mukherjee
0001-Introduce-the-ability-to-enable-disable-indexes.patch
Description: Binary data
at 6:44 PM, David Rowley wrote:
>
> On Mon, 23 Sept 2024 at 05:43, Shayon Mukherjee wrote:
>> - Modified get_index_paths() and build_index_paths() to exclude disabled
>> indexes from consideration during query planning.
>
> There are quite a large number of other pla
Hello,
I realized there were some white spaces in the diff and a compiler warning
error from CI, so I have fixed those and the updated patch with v2 is now
attached.
Shayon
On Sun, Sep 22, 2024 at 1:42 PM Shayon Mukherjee wrote:
> Hello,
>
> Thank you for all the feedback and insig
On Mon, Sep 23, 2024 at 8:31 PM David Rowley wrote:
> On Tue, 24 Sept 2024 at 03:14, Peter Eisentraut
> wrote:
> >
> > On 09.09.24 23:38, Shayon Mukherjee wrote:
> > > ALTER INDEX index_name ENABLE;
> > > ALTER INDEX index_name DISABLE;
> >
> >
09.09.24 23:38, Shayon Mukherjee wrote:
>> *Problem*:
>> Adding and removing indexes is a common operation in PostgreSQL. On larger
>> databases, however, these operations can be resource-intensive. When
>> evaluating the performance impact of one or more indexes, dropping them
aoss.co.jp
Thank you
Shayon
> On Sep 23, 2024, at 4:51 PM, Shayon Mukherjee wrote:
>
> That's a good point.
>
> +1 for the idea of the GUC setting, especially since, as you mentioned, it
> allows unprivileged users to access it and being per-session..
>
> I am hap
happy to work
accordingly on the patch.
Thank you
Shayon
On Tue, Sep 24, 2024 at 12:38 AM Maciek Sakrejda
wrote:
> If one of the use cases is soft-dropping indexes, would a GUC approach
> still support that? ALTER TABLE?
>
--
Kind Regards,
Shayon Mukherjee
v1-0001-Proof-of-Concept-Ability-to-enable-disable-indexe.patch
Description: Binary data
Thank you for the historical context and working, I understand what you were
referring to before now.
Shayon
> On Sep 24, 2024, at 2:08 PM, Peter Eisentraut wrote:
>
> On 23.09.24 22:51, Shayon Mukherjee wrote:
>> I am happy to draft a patch for this as well. I think I have a
> On Sep 24, 2024, at 9:19 AM, Shayon Mukherjee wrote:
>
> --
> Kind Regards,
> Shayon Mukherjee
>
Hello,
Also added this as a post in Commit Fest [0]
[0] https://commitfest.postgresql.org/50/5274/
Thank you
Shayon
> On Sep 26, 2024, at 1:39 PM, Shayon Mukherjee wrote:
>
> Hello,
>
> I am back with a PATCH :). Thanks to everyone in the threads for all the
> h
> On Nov 5, 2024, at 10:55 AM, Robert Haas wrote:
>
> On Thu, Oct 17, 2024 at 9:59 AM Shayon Mukherjee wrote:
>> My take away from whether or not an in-place update is needed on pg_index [1]
>>
>> - It’s unclear to me why it’s needed.
>> - I understand the xmin
On Fri, Dec 6, 2024 at 11:24 AM Shayon Mukherjee wrote:
> The patch is also rebased against the latest master and passing in CI.
> Would love to receive any further feedback on it.
>
>
Rebased the last patch against the latest master from today as a v5. No
other changes since last p
On Mon, Dec 30, 2024 at 11:08 AM Michail Nikolaev <
michail.nikol...@gmail.com> wrote:
> Hello.
>
> A few comments on patch:
>
Thank you for the feedback.
>
> > + temporarily reducing the overhead of index maintenance
> > + during bulk data loading operations
>
>>
>
But tuples are still ins
On Sun, Feb 2, 2025 at 3:11 PM jian he wrote:
> hi.
> the following reviews based on
> v10-0001-Introduce-the-ability-to-set-index-visibility-us.patch.
>
> Thank you for the amazing review!!
> in src/test/regress/sql/create_index.sql
> seems there are no sql tests for "create index ... invisibl
On Fri, Jan 31, 2025 at 10:18 AM Sami Imseih wrote:
>
> What is being discussed here is different from what I can tell. This
> is referring
> to the index changing status ( visible/invisible ) and those changes being
> visible by another transaction.
>
>
+1. My vote would be to keep the behavior
On Fri, Jan 24, 2025 at 4:03 PM Benoit Lobréau
wrote:
> I did notice something in the command prototype:
>
> +ALTER INDEX [ IF EXISTS ] class="parameter">name VISIBLE
> +ALTER INDEX [ IF EXISTS ] class="parameter">name INVISIBLE
>
> it would probably be better as:
>
> +ALTER INDEX [ IF EXISTS
On Fri, Jan 24, 2025 at 8:56 PM Benoit Lobréau
wrote:
> I also noticed that \d on an index doesn't warn about the invisible state
> whereas \d on a table does:
>
Thank you for the review + patch (v9-002) [1]. Your patch looks good to me.
I have not incorporated this in my v10 patch [2]. Mostly t
On Mon, Nov 25, 2024 at 6:19 PM David Rowley wrote:
> Another safer option could be to disallow the enable/disable ALTER
> TABLE if indcheckxmin is true. We do have and use
> ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE for these sorts of issues.
> There are other existing failure modes relating to i
On Fri, Jan 3, 2025 at 4:09 PM Sami Imseih wrote:
> + This is the
> + default state for newly created indexes.
>
> This is not needed in the ALTER INDEX docs, IMO.ss
>
> Updated and attached the patch.
> This got me thinking if dropping the index is the only
> use case we really care
On Sat, Jan 11, 2025 at 5:50 PM Sami Imseih wrote:
> Here is a use-case where the GUC may be useful. I can see a user
> wanting to try out the index before committing to using it across the
> board. They can create the index as invisible and force using
> it in a specific part of the application.
On Mon, Dec 30, 2024 at 2:56 PM Sami Imseih wrote:
> > Rebased with the latest master as well.
>
> Hi,
>
> This is a great, long needed feature. Thanks for doing this.
>
> I am late to this thread, but I took a look at the current patch
> and have some comments as I continue to look.
>
>
Thank yo
On Mon, Dec 30, 2024 at 3:48 PM Michail Nikolaev
wrote:
> Hello!
>
> One more thing (maybe I missed it in the patch, but anyway) - should we
> add some migration to ensure what old databases will get enabled=true by
> default after upgrade?
>
Hi!
Thank you! I tested this by manually upgrading (
momentum going on this (absolutely no
rush however). Just seeking feedback :).
Thank you
Shayon
> On Mar 7, 2025, at 2:21 AM, Shayon Mukherjee wrote:
>
> On Sun, Feb 23, 2025 at 3:41 PM Shayon Mukherjee <mailto:shay...@gmail.com>> wrote:
>> I have rebased the patch on
On Wed, Apr 2, 2025 at 10:53 PM Sami Imseih wrote:
> > That seems like a very good location for this advice. But the current
> > set of bullet points are all directed towards "... a general procedure
> > for determining which indexes to create". I propose that a new paragrph,
> > not a bullet poi
COMPLETE_WITH("VISIBLE", "INVISIBLE");
>
> /* CREATE OR REPLACE */
> else if (Matches("CREATE", "OR"))
>
> IMO, with the above in place, this patch is RFC.
>
>
>
Thank you Sami, really appreciate it!
Attach
On Tue, Apr 1, 2025 at 2:41 PM Sami Imseih wrote:
> I went back to look at this patch and a few things. I noticed it did
> not have correct
> indentation, so I ran pgindent. I also removed some extra lines added and
> made
> some slight adjustments to the docs. Attached my edited patch as a txt.
bles in the specs as noted in [1]. The query suggested in [1] wasn't
encompassing all the indexes, hence the UNION ALL for WHERE i.indrelid =
'part_tbl'::regclass::oid.
[1]
https://www.postgresql.org/message-id/cacjufxfs_m7ngvfiz-duutawb7rqxrmo97wc5zezkw2zsmq...@mail.gmail.com
Thank
On Mon, Apr 7, 2025 at 5:39 PM Sami Imseih wrote:
> > Attached v16 with feedback and rebased.
>
> Thanks, and I realized the original tab-complete I proposed
> was not entirely correct. I fixed it and also shortened the
> commit message.
I was wondering about if the check needed to be more enco
On Sun, Feb 23, 2025 at 3:41 PM Shayon Mukherjee wrote:
> I have rebased the patch on top of master (resolving some merge
> conflicts), along with the meson changes (thank you for that).
>
Rebased against the latest master and attaching the v13 patch.
Thank you
Shayon
v13-0001-Intr
On Sat, Feb 8, 2025 at 12:41 AM jian he wrote:
> hi.
> ```
> drop table if exists idxpart;
> create table idxpart (a int, b int, c text) partition by range (a);
> create table idxpart1 (like idxpart);
> alter table idxpart attach partition idxpart1 for values from (0) to (10);
>
> create index id
truncate will happen on a future vacuum
- Updated ruby script.rb to make simple select calls with high concurrency
- Renamed the POC to be `v1`
Thank you
Shayon
On Tue, May 6, 2025 at 6:05 PM Shayon Mukherjee wrote:
> Hello hackers,
>
> I'd like to discuss an issue we obse
Thank you for engaging into the conversation and sharing your thoughts Sami
and Robert.
On Thu, May 8, 2025 at 2:57 PM Sami Imseih wrote:
> > actually determine you are in this situation, or how bad the situation
> > was, in order to know that setting truncate off would help? To that
>
>
That's
truncate from acquiring the `AccessExclusiveLock` and holding it for
an extended period of time.
The patch is definitely more of a proof of concept for now (it lacks some
tests and maybe even some configurable params?) and more importantly I am
also curious to hear from the community if this feels l
44 matches
Mail list logo
