Search Postgresql Archives

Re: Filtering by UUID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well then...just like that you made me feel like a total idiot! Hah.

I guess that would work fine. I just need to encode some additional information in the pagination links that the API returns (a pagination "marker" would be a combination of created_at and uuid).

I know this question is virtually impossible to answer without more information, but based on your gut - do you think it would make sense to define a compound index across (created_at, uuid), or do you think just an index on created_at is enough, if we can assume that most records (>80%) won't have collisions on their created_at timestamp?

Thanks!
Colin

On Thu, Sep 29, 2016 at 7:09 PM Guyren Howe <guyren@xxxxxxxxx> wrote:
On Sep 29, 2016, at 16:03 , Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
>
> Hey list,
>
> I'm using UUID primary keys in my application. I need to add pagination, and am trying to avoid OFFSET/LIMIT. I do have a created_at timestamp that I could use, but it's possible for multiple records to be created at the same timestamp (postgres offers millisecond precision here, I believe?)
>
> Is there an efficient way to filter based on the time component of UUID v1s? WHERE id > 'some-uuid' doesn't seem to work, as it looks like it's just performing a lexicographic sort on the hex representation of the UUID. Or, alternatively, does anyone have other suggestions on paginating large data sets?

Why not just sort on (created_at, uuid) (ie us the UUID just to force a complete ordering)?


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux