Skip site navigation (1) Skip section navigation (2)

Re: WIP: cross column correlation ...

From: Rod Taylor <rod(dot)taylor(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Subject: Re: WIP: cross column correlation ...
Date: 2011-02-26 13:38:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Feb 25, 2011 at 14:26, Alvaro Herrera <alvherre(at)commandprompt(dot)com>wrote:

> Excerpts from Rod Taylor's message of vie feb 25 14:03:58 -0300 2011:
> > How practical would it be for analyze to keep a record of response times
> for
> > given sections of a table as it randomly accesses them and generate some
> > kind of a map for expected response times for the pieces of data it is
> > analysing?
> I think what you want is random_page_cost that can be tailored per
> tablespace.
Yes, that can certainly help but does nothing to help with finding typical
hot-spots or cached sections of the table and sending that information to
the planner.

Between Analyze random sampling and perhaps some metric during actual IO of
random of queries we should be able to determine and record which pieces of
data tend to be hot/in cache, or readily available and what data tends not
to be.

If the planner knew that the value "1" tends to have a much lower cost to
fetch than any other value in the table (it is cached or otherwise readily
available), it can choose a plan better suited toward that.

In response to


pgsql-hackers by date

Next:From: Dean RasheedDate: 2011-02-26 13:41:43
Subject: Re: wCTE: why not finish sub-updates at the end, not the beginning?
Previous:From: Greg StarkDate: 2011-02-26 13:31:16
Subject: Re: wCTE: why not finish sub-updates at the end, not the beginning?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group