Hi!
Please advise on the status of this patch set - are there any improvements?
Is there any work going on?
Thanks!
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
On 2022-11-30 2:30 p.m., Greg Stark wrote:
On Tue, 29 Nov 2022 at 21:16, Tom Lane wrote:
I actually think that that problem should be soluble with a
slightly different approach. The thing that feels insoluble
is that you can't do this without acquiring sufficient locks
to prevent addition of
On 2022-11-29 6:16 p.m., Tom Lane wrote:
Assuming that you are inserting into index X, and you've checked
index Y to find that it has no conflicts, what prevents another
backend from inserting a conflict into index Y just after you look?
AIUI the idea is to prevent that by continuing to hold an
On 2022-12-19 7:51 a.m., Nikita Malakhov wrote:
Sorry to bother - but is this patch used in IvorySQL?
Here:
https://www.ivorysql.org/docs/Global%20Unique%20Index/create_global_unique_index
According to syntax it definitely looks like this patch.
The global unique index is one of the features
Hi!
Sorry to bother - but is this patch used in IvorySQL?
Here:
https://www.ivorysql.org/docs/Global%20Unique%20Index/create_global_unique_index
According to syntax it definitely looks like this patch.
Thank you!
On Sat, Dec 3, 2022 at 3:05 AM David Zhang wrote:
> On 2022-11-29 6:16 p.m., Tom
On 2022-11-29 6:16 p.m., Tom Lane wrote:
Assuming that you are inserting into index X, and you've checked
index Y to find that it has no conflicts, what prevents another
backend from inserting a conflict into index Y just after you look?
AIUI the idea is to prevent that by continuing to hold an
Thanks a lot for all the comments.
On 2022-11-29 3:13 p.m., Tom Lane wrote:
... not to mention creating a high probability of deadlocks between
concurrent insertions to different partitions. If they each
ex-lock their own partition's index before starting to look into
other partitions'
On Tue, 29 Nov 2022 at 21:16, Tom Lane wrote:
>
> I actually think that that problem should be soluble with a
> slightly different approach. The thing that feels insoluble
> is that you can't do this without acquiring sufficient locks
> to prevent addition of new partitions while the insertion
On Wed, 2022-11-30 at 10:09 +0100, Vik Fearing wrote:
> On 11/29/22 17:29, Laurenz Albe wrote:
> > On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
> > > I disagree. A user does not need to know that a table is partitionned,
> > > and if the user wants a unique constraint on the table then
On 11/29/22 17:29, Laurenz Albe wrote:
On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
I disagree. A user does not need to know that a table is partitionned,
and if the user wants a unique constraint on the table then making them
type an extra word to get it is just annoying.
Hmm. But
On Tue, Nov 29, 2022 at 09:16:23PM -0500, Tom Lane wrote:
> Assuming that you are inserting into index X, and you've checked
> index Y to find that it has no conflicts, what prevents another
> backend from inserting a conflict into index Y just after you look?
> AIUI the idea is to prevent that by
Bruce Momjian writes:
> On Tue, Nov 29, 2022 at 06:13:56PM -0500, Tom Lane wrote:
>> ... not to mention creating a high probability of deadlocks between
>> concurrent insertions to different partitions. If they each
>> ex-lock their own partition's index before starting to look into
>> other
On Tue, Nov 29, 2022 at 06:13:56PM -0500, Tom Lane wrote:
> Greg Stark writes:
> > If I understand correctly you're going to insert into the local index
> > for the partition using the normal btree uniqueness implementation.
> > Then while holding an exclusive lock on the index do lookups on
Greg Stark writes:
> If I understand correctly you're going to insert into the local index
> for the partition using the normal btree uniqueness implementation.
> Then while holding an exclusive lock on the index do lookups on every
> partition for the new key. Effectively serializing inserts to
On Fri, 25 Nov 2022 at 20:03, David Zhang wrote:
>
> Hi Bruce,
>
> Thank you for helping review the patches in such detail.
>
> On 2022-11-25 9:48 a.m., Bruce Momjian wrote:
>
> Looking at the patch, I am unclear how the the patch prevents concurrent
> duplicate value insertion during the
On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
> I disagree. A user does not need to know that a table is partitionned,
> and if the user wants a unique constraint on the table then making them
> type an extra word to get it is just annoying.
Hmm. But if I created a primary key without
On 11/24/22 19:15, Cary Huang wrote:
On Thu, 24 Nov 2022 08:00:59 -0700 Thomas Kellerer wrote ---
> Pavel Stehule schrieb am 24.11.2022 um 07:03:
> > There are many Oracle users that find global indexes useful despite
> > their disadvantages.
> >
> > I have seen
On Fri, Nov 18, 2022 at 12:03:53PM +0300, Sergei Kornilov wrote:
> Hello
> Do we need new syntax actually? I think that a global unique index can be
> created automatically instead of raising an error "unique constraint on
> partitioned table must include all partitioning columns"
I may
On Fri, Nov 25, 2022 at 05:03:06PM -0800, David Zhang wrote:
> Hi Bruce,
>
> Thank you for helping review the patches in such detail.
>
> On 2022-11-25 9:48 a.m., Bruce Momjian wrote:
>
> Looking at the patch, I am unclear how the the patch prevents concurrent
> duplicate value
Hi Bruce,
Thank you for helping review the patches in such detail.
On 2022-11-25 9:48 a.m., Bruce Momjian wrote:
Looking at the patch, I am unclear how the the patch prevents concurrent
duplicate value insertion during the partitioned index checking. I am
actually not sure how that can be
On Mon, Nov 21, 2022 at 12:33:30PM +, Simon Riggs wrote:
> On Thu, 17 Nov 2022 at 22:01, Cary Huang wrote:
> >
> > Patch: Global Unique Index
>
> Let me start by expressing severe doubt on the usefulness of such a
> feature, but also salute your efforts to contribut
On Fri, Nov 25, 2022 at 8:49 AM Dilip Kumar wrote:
>
> On Thu, Nov 24, 2022 at 9:39 PM Justin Pryzby wrote:
> > On Thu, Nov 24, 2022 at 08:52:16PM +0530, Dilip Kumar wrote:
> > > but now you will have one gigantic index and which will be vacuumed
> > > every time we vacuum any of the partitions.
On Thu, Nov 24, 2022 at 9:39 PM Justin Pryzby wrote:
> On Thu, Nov 24, 2022 at 08:52:16PM +0530, Dilip Kumar wrote:
> > but now you will have one gigantic index and which will be vacuumed
> > every time we vacuum any of the partitions.
>
> This patch isn't implemented as "one gigantic index",
On Thu, 24 Nov 2022 08:00:59 -0700 Thomas Kellerer wrote ---
> Pavel Stehule schrieb am 24.11.2022 um 07:03:
> > There are many Oracle users that find global indexes useful despite
> > their disadvantages.
> >
> > I have seen this mostly when the goal was to get the
On Thu, Nov 24, 2022 at 07:03:24AM +0100, Pavel Stehule wrote:
> I can imagine a unique index on partitions without a special mark, that
> will be partitioned,
That exists since v11, as long as the index keys include the partition
keys.
> and a second variant classic index created over a
On Fri, Nov 18, 2022 at 3:31 AM Cary Huang wrote:
>
> Patch: Global Unique Index
> - Optimizer, query planning and vacuum -
> Since no major modification is done on global unique index's structure and
> storage, it works in the same way as a regular partitioned index. No
Pavel Stehule schrieb am 24.11.2022 um 07:03:
> There are many Oracle users that find global indexes useful despite
> their disadvantages.
>
> I have seen this mostly when the goal was to get the benefits of
> partition pruning at runtime which turned the full table scan (=Seq
st 23. 11. 2022 v 23:42 odesílatel Thomas Kellerer napsal:
> Tom Lane schrieb am 18.11.2022 um 16:06:
> >> Do we need new syntax actually? I think that a global unique index
> >> can be created automatically instead of raising an error "unique
> >> constraint on partitioned table must include
Tom Lane schrieb am 18.11.2022 um 16:06:
Do we need new syntax actually? I think that a global unique index
can be created automatically instead of raising an error "unique
constraint on partitioned table must include all partitioning
columns"
I'm not convinced that we want this feature at
> regular unique index:tps = 0.054367
-> global unique index: tps = 57.740432
thank you very much and we hope this information could help clarify some
concerns about this approach.
David and Cary
============
On Thu, 17 Nov 2022 at 22:01, Cary Huang wrote:
>
> Patch: Global Unique Index
Let me start by expressing severe doubt on the usefulness of such a
feature, but also salute your efforts to contribute.
> In other words, a global unique index and a regular partitioned index are
>
pá 18. 11. 2022 v 16:06 odesílatel Tom Lane napsal:
> Sergei Kornilov writes:
> > Do we need new syntax actually? I think that a global unique index can
> be created automatically instead of raising an error "unique constraint on
> partitioned table must include all partitioning columns"
>
>
Sergei Kornilov writes:
> Do we need new syntax actually? I think that a global unique index can be
> created automatically instead of raising an error "unique constraint on
> partitioned table must include all partitioning columns"
I'm not convinced that we want this feature at all: as far as
pá 18. 11. 2022 v 10:04 odesílatel Sergei Kornilov napsal:
> Hello
> Do we need new syntax actually? I think that a global unique index can be
> created automatically instead of raising an error "unique constraint on
> partitioned table must include all partitioning columns"
>
+1
Pavel
>
Patch: Global Unique Index
“Global unique index” in our definition is a unique index on a partitioned
table that can ensure cross-partition uniqueness using a non-partition key.
This work is inspired by this email thread, “Proposal: Global Index” started
back in 2019 (Link below). My
35 matches
Mail list logo
