| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Mohan Radhakrishnan <radhakrishnan(dot)mohan(at)gmail(dot)com> |
| Cc: | PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Primary keys and composite unique keys(basic question) |
| Date: | 2021-03-31 16:03:21 |
| Message-ID: | CAHOFxGr9yhQEN=Fw3A4aqTA+RsdhCVzxfeSCdVzJRq7xW2shuQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Etiquette on these lists is to reply in line or below the relevant portion,
not top-post with full quoting like default gmail behavior.
On Wed, Mar 31, 2021 at 9:18 AM Mohan Radhakrishnan <
radhakrishnan(dot)mohan(at)gmail(dot)com> wrote:
> But we don't search using UUIDs always. Only when data from another
> distributed service
> is received we need them and in such cases we have to join using them.
>
I haven't used them so I don't recall exactly, but I believe there is a
type of UUID generation which has some leading correlation to time which
would help with reducing the random I/O issue that Tom Lane mentioned. A
quick search of the archive may lead you to that, or someone else may chime
in with the name I expect.
> But for local data we can identify another composite unique key. Does
> PostgreSql
> create a unique index for us ? What about a FK that references this
> composite
> unique key ? Does it create a FK index ?
>
It is up to you to create whichever fkeys and indexes you require.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc-Olaf Jaschke | 2021-03-31 16:26:52 | concurrent creation of sequences |
| Previous Message | Jain, Ankit | 2021-03-31 15:58:51 | RE: Issues with using plpgsql debugger using PG13 on Centos 7 |