Primary keys and composite unique keys(basic question)

Hello, We have UUIDs in our tables which are primary keys. But in some cases we also identify a composite unique key apart from the primary key. My assumption is that there should be a unique key index created by us using the composite key. And when we fetch using this composite key i

Re: Primary keys and composite unique keys(basic question)

Thank you. On Wed, Mar 31, 2021 at 7:42 PM Tom Lane wrote: > Mohan Radhakrishnan writes: > > We have UUIDs in our tables which are primary keys. But in > > some cases > > we also identify a composite unique key apart from the primary key. > > > My assumpti

Storing state machine

Hello, We have a workflow when we receive events into the service. But we don't have a way to choreograph or orchestrate the workflow. The services are all independent and receive and respond to events. Since there is no order imposed by the event queues I was thinking of storing a simp

Re: Storing state machine

sed to check easily instead of checking it children. Thanks. On Mon, Apr 19, 2021 at 12:21 PM Tim Cross wrote: > > Mohan Radhakrishnan writes: > > > Hello, > >We have a workflow when we receive events into the service. > But we don't have a way to chore

Re: Storing state machine

rtain type of index like the BRIN index for ordering timestamptz ? I have to exclude already processed records. Thanks. On Mon, Apr 19, 2021 at 6:40 PM Mohan Radhakrishnan < radhakrishnan.mo...@gmail.com> wrote: > >Your requirement statement is extremely simple and I suspect you have

BRIN index on timestamptz

Hi, I am planning to use as I search based on timestamptz fields. There are millions of records.I refer https://www.percona.com/blog/2019/07/16/brin-index-for-postgresql-dont-forget-the-benefits I execute this on the AWS RDS instance. Is there something in the plan I should pay attention

Re: BRIN index on timestamptz

>a) You need to do ANALYZE, otherwise >there are no statistics the optimizer >could use I execute and analyze. The actual timestamps I have are not random. I will order them chronologically. Thanks On Saturday, April 24, 2021, Tomas Vondra wrote: > > > On 4/23/21 10:31 AM, M

Re: BRIN index on timestamptz

gt; > > On Sat, Apr 24, 2021, 1:27 AM Mohan Radhakrishnan < > radhakrishnan.mo...@gmail.com> wrote: > >> What's your question exactly? If you have confidence that correlation >> will remain high (insert only table, or occasional cluster/repack with >> c

Re: BRIN index on timestamptz

Isn't a btree subject to these effects ? So when I update ENUMS for each timestamptz, btree indexes are less susceptible to the effects than BRIN indexes ? Thanks. On Sat, Apr 24, 2021 at 9:05 PM Mohan Radhakrishnan < radhakrishnan.mo...@gmail.com> wrote: > > Why not use a bt