Re: Plan time Improvement - 64bit bitmapset

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Andres Freund" <andres(at)anarazel(dot)de>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Plan time Improvement - 64bit bitmapset
Date: 2009-06-03 20:42:11
Message-ID: 4A2699D3020000250002743D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> When you say, "don't fit in cache", exactly what
> cache are you talking about? It seems to me that the statistics
> should be far smaller than the underlying tables, so if even your
> statistics don't fit in shared buffers (let alone main memory), it
> doesn't really matter how long your query takes to plan because it
> will probably take literally forever to execute. How many tables
> would you have to be joining to get a GB of statistics, even with
> dst = 1000? A few hundred?

Since he can't share the schema, and hasn't even given much of a hint,
I don't know whether one (or more) of the columns is a bytea filled
with 100 MB values; and I don't remember any description of the
hardware environment either. Since the behavior seems so
out-of-the-ordinary, I was casting about for possible extraordinary
characteristics of his environment which might cause it. I'm probably
way off base....

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Emmanuel Cecchet 2009-06-03 20:50:46 Re: Locks on temp table and PREPARE
Previous Message Robert Haas 2009-06-03 20:18:49 Re: Plan time Improvement - 64bit bitmapset