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 n
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 e
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 re
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 e
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' indexes,
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 is
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 ma
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 part
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 every
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 t
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 partitio
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 thi
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 suggest
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 insertion
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 done
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", thou
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 benefi
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 partiti
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. N
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 Scan)
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 all
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 all:
:tps = 0.008209
-> 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
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
> ess
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"
>
> I'm
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
> regar
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
