From: | Alexandre Leclerc <alexandre(dot)leclerc(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, PERFORM <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Flattening a kind of 'dynamic' table |
Date: | 2005-02-04 20:08:56 |
Message-ID: | 1dc7f0e305020412085bef5611@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 4 Feb 2005 12:48:43 -0500, Merlin Moncure
<merlin(dot)moncure(at)rcsonline(dot)com> wrote:
> > Alexandre Leclerc wrote:
> > Sorry for jumping in on this thread so late -- I haven't been able to
> > select * from crosstab(
> > 'select product_id, department_id, req_time
> > from product_department_time order by 1',
> > 'select ''A'' union all select ''C'' union all select ''D'''
> > ) as (product_id int, a int, c int, d int);
>
> I forgot you could do this...This would certainly be easier than parsing
> array values returned from array_accum. It will probably be faster as
> well...but with the array approach the query would not have to be
> modified each time a new department was added. That said, a crosstab
> based query could be built easily enough from a department query on the
> client and then you have the best of both worlds.
Hello Merlin,
Well, I'm glad because with all this i've learn a lot of new things.
Finally, the crosstab solution is very fast and is simple for me to
use. I get my super-bug-jumbo-dbkiller-query run in about 210ms
(seeking many tables and so). I had a score of 2480ms before. (This is
a much more complex query; the cross table thing had to be included in
this one.) This is much better! :)
In all, thanks for your help. Regards.
--
Alexandre Leclerc
From | Date | Subject | |
---|---|---|---|
Next Message | Marinos Yannikos | 2005-02-05 13:01:40 | Re: GiST indexes and concurrency (tsearch2) |
Previous Message | Sanketh Indarapu | 2005-02-04 19:29:36 | Postgres odbc performance on windows |