Folks, thanks everyone for the valuable inputs, I think I more-or-less
understand now what the options are for my particular problem.
On Wed, Feb 26, 2025, at 17:14, Peter Geoghegan wrote:
> On Wed, Feb 26, 2025 at 10:40 AM wrote:
> > Does this mean that it is not possible to come up with a plan
On Wed, 2025-02-26 at 15:27 +0100, large.goose2...@salomvary.com wrote:
> I am working on optimizing a query that attempts to efficiently paginate
> through a large table using multi-column "cursors" aka. the "seek method"
> (as described in detail here:
> https://use-the-index-luke.com/sql/partial
On Wed, Feb 26, 2025 at 10:40 AM wrote:
> My understanding is that given this "mixed order" index:
> CREATE INDEX data_index_desc ON data (col_1, col_2 DESC, col_3);
>
> The index tuples are physically organized exactly in this way:
> ORDER BY col_1, col_2 DESC, col_3
>
> So that I should be able
Thanks for the insights!
On Wed, Feb 26, 2025, at 16:05, Peter Geoghegan wrote:
> On Wed, Feb 26, 2025 at 9:29 AM wrote:
> > Without being familiar the internals of the query planner, I *think* there
> > *should* be a way to come up with WHERE conditions that results in the
> > "perfect" plan.
On Wed, Feb 26, 2025 at 9:29 AM wrote:
> Without being familiar the internals of the query planner, I *think* there
> *should* be a way to come up with WHERE conditions that results in the
> "perfect" plan.
There is a fundamental trade-off involved here. The simple, fast
"WHERE (col_1, col_2, c
Hi folks,
I am working on optimizing a query that attempts to efficiently paginate
through a large table using multi-column "cursors" aka. the "seek method" (as
described in detail here:
https://use-the-index-luke.com/sql/partial-results/fetch-next-page).
The table (drastically simplified) loo
