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)
Hello,
I've inherited some very...interestingly...
designed tables, and am trying to figure out how to make them usable. I've
got an ugly hack in place, but it will not use an index properly, and I'm
hoping someone will be able to point me in the right direction.
Production is running 8.1.3, but
