From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martin Handsteiner <martin(dot)handsteiner(at)sibvisions(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-sql(at)lists(dot)postgresql(dot)org" <pgsql-sql(at)lists(dot)postgresql(dot)org> |
Subject: | Re: AW: Optimizer Hint, to ignore limit and offset in optimizer plan |
Date: | 2020-06-29 14:30:19 |
Message-ID: | 323666.1593441019@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Martin Handsteiner <martin(dot)handsteiner(at)sibvisions(dot)com> writes:
> yes, this would exactly be the feature I was talking about.
> enable_costlimit = true (default) | false
> How high is the possibility, that this feature will find the way into the postgres db?
Not very good, unless you can present a far more convincing use-case.
If I understand your desire, it is that issuing the "same" query in
different transactions would generate identical overall results
despite varying the offset/limit so as to fetch different parts of
that unchanging result.
The problem with this is that whether changing the offset/limit
changes the plan shape is just one of many reasons why you might
not get a consistent result --- the most unavoidable being that
other transactions might commit data changes.
Moreover, you insist that you shouldn't have to use an ORDER BY
to get these consistent results. Sorry, but SQL is *defined* to
not produce consistent row ordering without ORDER BY. Changing
that isn't a matter of some optimizer hint somewhere, it's a very
fundamental thing in many places.
I'd counsel taking another look at the suggestion made upthread
to use a cursor WITH HOLD.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Brandsberg | 2020-06-29 14:33:43 | Re: AW: Optimizer Hint, to ignore limit and offset in optimizer plan |
Previous Message | Martin Handsteiner | 2020-06-29 08:10:34 | AW: Optimizer Hint, to ignore limit and offset in optimizer plan |