Re: bad estimates

Bruno Wolff III wrote:
> Can you do a \d on the real table or is that too sensitive?

It was silly of me to think of this as particularly sensitive.

stocks=> \d day_ends
         Table "public.day_ends"
    Column   |     Type     | Modifiers
------------+--------------+-----------
  stock_id   | integer      | not null
  price_date | date         | not null
  open       | numeric(9,4) |
  high       | numeric(9,4) |
  low        | numeric(9,4) |
  close      | numeric(9,4) |
  volume     | integer      |
Indexes: day_ends_pkey primary key btree (stock_id, price_date)
Triggers: RI_ConstraintTrigger_16558399

> It still doesn't make sense that you have a primary key that
> is a stock and its price. What happens when the stock has the
> same price on two different dates? And I doubt that you are looking
> for the minimum and maximum dates for which you have price data.
> So it is hard to believe that the index for your primary key is the
> one you need for your query.

I can see the naming being confusing.  I used "price_date" because, of 
course, "date" is not a legal name.  "day_ends" is a horrible name for 
the table; "daily_bars" would probably be better.  I *am* looking for 
the mininum and maximum dates for which I have price data.  I'm running 
this query to build a chart so I can see visually where the majority of 
my data begins to use as the start of a window for analysis.

When run on 7.3.3, forcing an index scan by setting 
enable_seqscan=false, the query took 55 minutes to run.  The index is 
about 660M in size, and the table is 1G.  As I mentioned before, with 
table scans enabled, it bombs, running out of temporary space.

Hey Bruno, thanks for your attention here.  I'm not a newbie, but I've 
never really had performance issues with pgsql before.  And I've been 
running this database for a couple of years now, but I haven't run these 
queries against it.


Ken