Re: Plan time Improvement - 64bit bitmapset - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Plan time Improvement - 64bit bitmapset
Date
Msg-id 4A2699D3020000250002743D@gw.wicourts.gov
Whole thread Raw
In response to Re: Plan time Improvement - 64bit bitmapset  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Plan time Improvement - 64bit bitmapset  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Plan time Improvement - 64bit bitmapset  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Plan time Improvement - 64bit bitmapset
Next
From: Emmanuel Cecchet
Date:
Subject: Re: Locks on temp table and PREPARE