| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> | 
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: VACUUM ANALYZE is faster than ANALYZE? | 
| Date: | 2012-02-23 08:34:18 | 
| Message-ID: | CA+U5nMKUGRz9EJQoig-pJqWcdPE3haZC8iV+3nXK8MvHz5q8mg@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Wed, Feb 22, 2012 at 10:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Feb 22, 2012 at 2:23 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> The industry accepted description for non-sequential access is "random
>> access" whether or not the function that describes the movement is
>> entirely random. To argue otherwise is merely hairsplitting.
>
> I don't think so.
PostgreSQL already uses  a parameter called "random_page_cost" to
describe non-sequential access. Perhaps that is wrong and we need a
third parameter?
> For example, a bitmap index scan contrives to speed
> things up by arranging for the table I/O to happen in ascending block
> number order, with skips, rather than in random order, as a plain
> index scan would do, and that seems to be a pretty effective
> technique.  Except to the extent that it interferes with the kernel's
> ability to do readahead, it really can't be to read blocks 1, 2, 3, 4,
> and 5 than to read blocks 1, 2, 4, and 5.  Not reading block 3 can't
> require more effort than reading it.
By that argument, ANALYZE never could run longer than VACUUM ANALYZE,
so you disagree with Tom and I and you can't explain Pavel's
results....
cost_bitmap_heap_scan() uses "random_page_cost" to evaluate the cost
of accessing blocks, even though the author knew the access was in
ascending block number order. Why was that?
Note that the cost_bitmap_heap_scan() cost can be > than
cost-seqscan() for certain parameter values.
-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2012-02-23 08:37:27 | Re: REASSIGN OWNED lacks support for FDWs | 
| Previous Message | Thom Brown | 2012-02-23 08:26:47 | Re: Triggers with DO functionality |