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

From Greg Stark
Subject Re: Plan time Improvement - 64bit bitmapset
Date
Msg-id CE6D8A0D-F31C-4438-999C-B0911E67DBA0@enterprisedb.com
Whole thread Raw
In response to Re: Plan time Improvement - 64bit bitmapset  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Plan time Improvement - 64bit bitmapset  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Doesn't that still add up to 3GB for a table's stats in the worst  
case? 1kb * 1,000 buckets * 1,500 attributes * 2 (histogram + mfv)

Except you can't actually get 1500 toast pointers on a page. I suppose  
with games with nulls you could make this worst case happen though.

It does seem like it ought to be possible to truncate strings in the  
histogram since any string between the actual values us equally good.

-- 
Greg


On 3 Jun 2009, at 22:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> 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....
>
> There's a hard-wired restriction in analyze.c that makes it discard  
> data
> values wider than 1KB on-sight.  So no such value will ever be found  
> in
> a statistics array.  You could still have a few meg in a pg_statistics
> row, I suppose, but not a really horrendous amount.
>
>            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Plan time Improvement - 64bit bitmapset
Next
From: Tom Lane
Date:
Subject: Re: Plan time Improvement - 64bit bitmapset