Re: Partitioning update-heavy queue with hash partitions vs partial indexes

2023-08-11 Thread Dorian Hoxha
@David Rowley Thanks for explaining. @Burcin I'm not too fond of the new column because it introduces a new index that needs to be maintained. I could change the index on `view_time` to `(shard_id, view_time)`, but I'm afraid that may increase the time to traverse the index (because all shard_id w

Re: Partitioning update-heavy queue with hash partitions vs partial indexes

2023-08-10 Thread burcinyazici
hi, Consider adding id%10 as a new column?you will have one time burden but after creating index on it, update perf will satisfy. Burcin 📱 > On 11 Aug 2023, at 07:49, David Rowley wrote: > > On Thu, 10 Aug 2023 at 20:36, Dorian Hoxha wrote: >>> Do Not Use Partial Indexes as a Substitute for

Re: Partitioning update-heavy queue with hash partitions vs partial indexes

2023-08-10 Thread David Rowley
On Thu, 10 Aug 2023 at 20:36, Dorian Hoxha wrote: > > Do Not Use Partial Indexes as a Substitute for Partitioning > > While a search in this larger index might have to descend through a couple > > more tree levels than a search in a smaller index, that's almost certainly > > going to be cheaper

Partitioning update-heavy queue with hash partitions vs partial indexes

2023-08-10 Thread Dorian Hoxha
Hi list, I have a queue table with the schema: ``` create table queue(id bigserial primary key, view_time timestamp with timezone not null); create index queue_view_time ON queue(view_time ASC); ``` The most concurrent operation is: ``` UPDATE queue SET view_time=view_time+INTERVAL '60 seconds'