On Tue, 6 Feb 2024 at 01:23, Sean v wrote:
> SELECT "orders".*
> FROM "orders"
> WHERE (user_id IN ?, ?, ?)
> ORDER BY "orders"."created_at" LIMIT 50
>
> I have two indexes - `(user_id)` and `(user_id, created_at)`. Only the first
> index is ever used with this query.
> I imagined that it would
El mié, 7 feb 2024 8:07, Sean v escribió:
> Exactly. I'm really just trying to understand if there's some functional
> limitation to it being able to do that with how it executes these types of
> queries, or if its just an optimization that hasn't been built into the
> query planner yet.
>
> I
On Mon, Feb 5, 2024 at 8:55 AM Ron Johnson wrote:
>
> Who knows which users are going to be in that list???
>
>
It doesn't matter. Worse case scenario there is only one user in the
result and so all 50 rows are their earliest 50 rows. The system will thus
never need more than the earliest 50
On Mon, Feb 5, 2024 at 7:23 AM Sean v wrote:
> This is related to a question I asked on dbs.stackexchange.com:
> https://dba.stackexchange.com/questions/335501/why-doesnt-postgres-apply-limit-on-groups-when-retrieving-n-results-per-group
>
> But to reiterate - I have a query like this:
>
>
This is related to a question I asked on dbs.stackexchange.com:
https://dba.stackexchange.com/questions/335501/why-doesnt-postgres-apply-limit-on-groups-when-retrieving-n-results-per-group
But to reiterate - I have a query like this:
SELECT "orders".*
FROM "orders"
WHERE (user_id IN ?, ?, ?)
