David Johnston wrote
> Your original examples only create the cursor and do not actually use it.
> You should be comparing how long it takes both examples to fetch the first
> 10 pages of records to get a meaningful comparison. It won't matter if
> the DECLARE only takes 3ms in the non-hold case
My use-case is just creating paginated list for a large table.
The first obvious option is offset limit but it works too slow for great
offset.
A lot of topics propose using cursors for that, so I am learning this
possibility.
You will say that there are other possibilities. Yes - but I am trying t
I wonder how quick is cursor without hold.
I have a data set with 10^7 rows.
*begin;
declare mycursor cursor for select * from z;
commit;
* - this takes 3 ms.
*begin;
declare mycursor cursor with hold for select * from z;
commit;
* - this takes 3 s.
Thus, holdable cursor is getting calculate
I firstly used 9.1.
After switching to 9.2. - the problem was fixed even without index only
scan.
I added another column to my table so this wasn't index only, but still had
better index behaviour.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-scan-and-bitmap-i
This seems to be fixed in 9.2.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-scan-and-bitmap-index-scan-hard-to-understand-how-planner-chooses-tp5760304p5760637.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-gene
Here is a script for initializing my database
*drop table if exists z;
create table z as select lpad(i::text,6,'0') as name from
generate_series(0,99) as i;
create index z_name on z(name text_pattern_ops);
analyze;
*
So - I have a table z with one column name that has textual index.
Now, I wa
