| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David Blewett" <david(at)dawninglight(dot)net> |
| Cc: | "PG Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pre-MED |
| Date: | 2008-10-30 03:27:04 |
| Message-ID: | 3769.1225337224@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"David Blewett" <david(at)dawninglight(dot)net> writes:
> Here's a vote for allowing this in plain SQL.
> I use the tablefunc contrib module as a way to build a view of a
> specific questionnaire's responses (using Elein's nice model here
> [1]). Currently, if I then write queries against these views that
> include WHERE clauses they don't perform very well as the underlying
> data size grows. I was using the afore-mentioned large view that casts
> everything to text, but recently I started using separate calls to the
> crosstab function for each underlying table, then joining them
> together based on their response ID. This seems to work much better
> for more complex queries, but I think it would still be beneficial to
> have access to these qualifiers so I could push down to each subquery
> the list of response ID's to pull. I don't have access to sample SQL
> at the moment, but if it is wanted I can try to get that this week.
Please. Some real use-cases would be very helpful here. I'm
particularly wondering whether the proposed deparse call actually yields
anything that's useful without extensive additional knowledge about
the query ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2008-10-30 03:28:07 | Re: Please make sure your patches are on the wiki page |
| Previous Message | Tom Lane | 2008-10-30 03:24:07 | Re: minimal update |