"Tom Lane" <[EMAIL PROTECTED]> writes: > We could probably fix this by complicating the logic in ExecUnique, > but I wonder whether it wouldn't be better to just stop treating > Unique nodes as backwards-scannable. The only reason for that > node type to exist (as opposed to using Group nodes) is that it's > simple and low-overhead. So complicating it to support a corner case > that no one has noticed in many years might be counterproductive. > Thoughts?
Hm, that has the nasty side effect that someone who uses SCROLL but doesn't fetch backwards much or at all suddenly gets a much more expensive plan than if they didn't. On the other hand someone who does actually use the scrollability of the cursor to fetch forward and backwards a lot, repeatedly fetching the same records, would actually get significantly better performance out of a materialized result than having to skip over the duplicates repeatedly. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
