JobId should be Int64 about odd-jobs

[mrputty]

FWIW, I don't think there's any value in making this configurable. The representation of the job id is an internal library concern, at least the way the library is structured today. I think just using Int64 seems the most reasonable to me.

[saurabhnanda]

If my calculation is right, even at one job / sec, it would take 17+ years to reach this limit.

Are you planning to use this instead of a message queue, by any chance?

[TomMD]

Are you planning to use this instead of a message queue, by any chance?

Ding ding!

[saurabhnanda]

Seriously? Are you planning to use odd-jobs instead of a message-queue? How many messages / sec are you expecting?

[TomMD]

Yes, seriously. I'd rather have my jobs persist and not be an in-memory store that could be lost in the event of an outage. I see perhaps 20 message per user per day. If I am super successful and see 10M users then thats 700 message / second spread over the 8 hour work day uniformly.

[jkachmar]

+1 for making JobId an Int64.

Is Int being used to address a particular problem with performance or overhead, or just because it's not an expected use-case for the queue to grow beyond 2^29 entries?

[saurabhnanda]

Is Int being used to address a particular problem with performance or overhead, or just because it's not an expected use-case for the queue to grow beyond 2^29 entries?

I didn't think through this deeply. What is the natural choice for mapping a Postgres integer to a Haskell data-type? How many bits does a Postgres integer use?

[TomMD]

How many bits does a Postgres integer use?

Postgres integer is 32 bits: https://www.postgresql.org/docs/10/datatype-numeric.html

bigint is 64 bits

[saurabhnanda]

So, ideally, if we make this change it should be int <=> Int and bigint <=> Int64, right?

Is there value in making this configurable? Or will it end-up being unnecessary complexity for library users for little gain?

[TomMD]

That makes sense to me, yes. There could be an argument for type JobId = Int64 too.