2009/11/20 Jonathan Foy :
> Shy of just throwing a trigger in the
> table to actually populate a second table with the same data solely for
> reporting purposes,
That's what I would do in your situation, FWIW. Query optimization is
a hard problem even under the best of circumstances; getting the
I don't think so. I actually dumped the tables involved into stripped down
versions of themselves in a new database for testing, so the data involved
should be completely fresh. I ran a vacuum analyze after the dump of
course.
Just for paranoia's sake though I did do the following:
explain analy
20 листопада 2009 р. 17:01 Jonathan Foy написав:
> This seems to result in the same problem; should I attempt to pull for a
> specific id_nbr/id_qfr, postgres uses the index without a problem. If I try
> to join the two tables/views however, it insists on doing a sequential scan
> (actually two i
This seems to result in the same problem; should I attempt to pull for a
specific id_nbr/id_qfr, postgres uses the index without a problem. If I try
to join the two tables/views however, it insists on doing a sequential scan
(actually two in this case) and will not use the index. Any other
ideas/e
How about
CREATE OR REPLACE VIEW value_codes_view AS
select * from (
SELECT value_codes.id_nbr,
value_codes.id_qfr,
(ARRAY[val_1_cd_1, ... , val_2_cd_12])[i] as value_code,
(ARRAY[val_1_amt_1, ... , val_2_amt_12])[i] as value_amount,
FROM value_codes, generate_series(1,24) i)
