On Sep 23, 2006, at 8:19 AM, Markus Schaber wrote:
Btw, would it be feasible to enhance normal index scans by looking at
all rows in the current table block whether they meet the query
criteria, fetch them all, and blacklist the block for further
revisiting
during the same index scan?
I think
Hi, Tom,
Tom Lane wrote:
> "Alex Turner" <[EMAIL PROTECTED]> writes:
>> Home come the query statistics showed that 229066 blocks where read given
>> that all the blocks in all the tables put together only total 122968?
>
> You forgot to count the indexes. Also, the use of indexscans in the
> mer
Ok - so I have another mystery:I insert virtually the same rows into two different tables:trend=# insert into fish select 2, nextval('result_entry_order_seq'), property_id from property;INSERT 0 59913
trend=# insert into result_entry select 0, nextval('result_entry_order_seq'), property_id from pro
ahh good pointThanksOn 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Alex Turner" <[EMAIL PROTECTED]> writes:> Home come the query statistics showed that 229066 blocks where read given> that all the blocks in all the tables put together only total 122968?
You forgot to count the indexes. Also,
"Alex Turner" <[EMAIL PROTECTED]> writes:
> Home come the query statistics showed that 229066 blocks where read given
> that all the blocks in all the tables put together only total 122968?
You forgot to count the indexes. Also, the use of indexscans in the
mergejoins probably causes multiple re-
