Re: Bitmap Heap Scan anomaly

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: jaba the mobzy <makaronaforna(at)yahoo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bitmap Heap Scan anomaly
Date: 2007-05-03 23:50:42
Message-ID: 1178236242.28383.304.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2007-05-03 at 14:33 -0700, jaba the mobzy wrote:
> mycorr_100 took 11.4 s to run although it had to fetch 100000 row from
> the base table.
> mycorr_10 took 24.4 s to run although it had to fetch 10563 row from
> the base table.

This is because the physical distribution of data is different. The
mycorr_10 table has tuples in which a and b are > 15.9M spread all
throughout. mycorr_100 has them all collected together at the end of the
physical file. Less disk seeking.

You can test this by doing a CLUSTER on both tables and run the same
queries again.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-05-04 01:13:45 pgsql: Teach tuplesort.c about "top N" sorting, in which only the first
Previous Message Alvaro Herrera 2007-05-03 22:50:44 Re: Grantor name gets lost when grantor role dropped