Tom Lane wrote:
Jack Orenstein writes:
Limit (cost=0.00..324.99 rows=100 width=451)
-> Index Scan using t_pkey on t (cost=0.00..296027.98 rows=91088
width=451)
Index Cond: (pk > 10)
Adding the value restriction at the top of this query plan wouldn't increase the
Jack Orenstein writes:
>Limit (cost=0.00..324.99 rows=100 width=451)
> -> Index Scan using t_pkey on t (cost=0.00..296027.98 rows=91088
> width=451)
>Index Cond: (pk > 10)
> Adding the value restriction at the top of this query plan wouldn't increase
> the
> cos
Sam Mason wrote:
On Mon, Jun 22, 2009 at 05:55:28PM -0400, Jack Orenstein wrote:
ris-# select *
ris-# from T
ris-# where pk > 10
ris-# and value = 'asdf'::bytea
ris-# order by pk
ris-# limit 100;
PG thinks that you're going to get 16 rows back matching those
conditions, bitmap heap sca
Sam Mason writes:
> On Mon, Jun 22, 2009 at 05:55:28PM -0400, Jack Orenstein wrote:
>> Why does adding the value restriction so radically change the execution
>> plan?
> PG doesn't have any cross column statistics and hence it assumes that pk
> and value are uncorrelated.
Even if they are corre
On Mon, Jun 22, 2009 at 05:55:28PM -0400, Jack Orenstein wrote:
> ris-# select *
> ris-# from T
> ris-# where pk > 10
> ris-# and value = 'asdf'::bytea
> ris-# order by pk
> ris-# limit 100;
PG thinks that you're going to get 16 rows back matching those
conditions, bitmap heap scans are fa
I have a table that looks like this:
create table T(pk int not null, value bytea, ..., primary key(pk))
I want to scan the table in batches of 100. I'll do this by issuing a sequence
of queries like this:
select *
from T
where pk > ?
and value = ?
order by pk
limit 1
