Re: I: About "Our CLUSTER implementation is pessimal" patch

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
Cc: Leonardo Francalanci <m_lists(at)yahoo(dot)it>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch
Date: 2010-10-04 03:45:02
Message-ID: AANLkTinTBU-SYp7PTXut1FDRtFZmOCCS=r3FL_GbJ7aG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 2, 2010 at 9:36 AM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> Hrm, this is interesting. I set up a test table with 5M rows like so:

Such discussions are for the planner itself, right? The sorted cluster
patch uses the existing planner's costing model, so we can discuss the
clustering feature and the improvement of planner in different patches.

> My seq_page_cost and random_page_cost were left at the defaults for
> these tests. Oddly, I tried turning seq_page_cost down to 0.01 and
> EXPLAIN ANALYZE told me that an index scan was still being chosen. Is
> there maybe some other setting I'm forgetting?

It might come from effective_cache_size. We consider the value only
in the index scans. We can also use the effective cache in addition
to work_mem for tapes used by disk sorting, but we don't consider
the effective cache for now.

--
Itagaki Takahiro

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-10-04 06:05:48 Re: patch: tsearch - some memory diet
Previous Message Steve Singer 2010-10-04 03:19:56 Re: Review: Fix snapshot taking inconsistencies