Re: pre-MED

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: Raw Message | Whole Thread | 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

In response to

  • Re: pre-MED at 2008-10-29 18:17:44 from David Blewett

Browse pgsql-hackers by date

  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