| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Yevhenii Kurtov <yevhenii(dot)kurtov(at)gmail(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: |
| Date: | 2017-06-30 17:46:45 |
| Message-ID: | CAMkU=1wU632cTJ4cc57+ExMQxumrDSXR5rbSoL2Fk1Ymrck1zA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Jun 29, 2017 at 12:11 PM, Yevhenii Kurtov <yevhenii(dot)kurtov(at)gmail(dot)com
> wrote:
> Hi Jeff,
>
> That is just a sample data, we are going live in Jun and I don't have
> anything real so far. Right now it's 9.6 and it will be a latest stable
> available release on the date that we go live.
>
You need to use your knowledge of the application to come up with some
plausible sample data.
What happens when something succeeds? Does it get deleted from the table,
or does it get retained but with a certain value of the status column? If
it is retained, what happens to the priority and times_failed fields?
The performance of your queuing table will critically depend on that.
If you need to keep it once it succeeds, you should probably do that by
deleting it from the queuing table and inserting it into a history table.
It is much easier to keep performance up with that kind of design.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daviramos Roussenq Fortunato | 2017-06-30 19:14:33 | Simple SQL too slow |
| Previous Message | Scott Marlowe | 2017-06-30 03:09:28 | Re: |