Re: Materialiation is slower than non-materialized

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Materialiation is slower than non-materialized
Date: 2015-03-24 02:31:42
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB77159877156@szxeml521-mbs.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23 March 2015 21:39, Robert Haas

> On Mon, Mar 23, 2015 at 6:01 AM, Rajeev rastogi
> <rajeev(dot)rastogi(at)huawei(dot)com> wrote:
> > The cost of re-scan of SeqScan node is considered to be same scan of
> > SeqScan node, which always assumes that the records is fetched from
> > disk and hence disk access cost is added (As we don’t know really how
> > much memory will be available to cache during execution).
>
> That's a general problem not limited to materialize nodes. We might
> choose to do a heap-sort rather than a quick-sort, but it may turn out
> that the "tapes" we create end up in the OS buffer cache instead of on
> physical storage; in fact, it's probably the common case. Scans are
> costed using seq_page_cost and random_page_cost, but most of the time
> the "random" page cost will not be the cost of a head seek, because
> we'll find the data in the OS page cache. Some of the time it really
> will be a head seek, but we have no idea whether that will happen in
> any given case. The autovacuum cost delays have this problem too: a
> "miss" in shared buffers may really be a hit in the OS page cache, but
> we don't know.

Yes, I agree.

> This kind of disclaimer is inappropriate on a public mailing list.
> Don't send confidential information to public mailing lists. You
> probably don't have any legal right to control what happens to it after
> that, regardless of what you put in your email.
Sorry for this. Generally we delete this legal message before sending mails to
community but somehow missed to do the same this time.

Thanks and Regards,
Kumar Rajeev Rastogi.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2015-03-24 02:33:26 Re: Exposing PG_VERSION_NUM in pg_config
Previous Message Etsuro Fujita 2015-03-24 02:15:53 Re: inherit support for foreign tables