| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Reg Me Please <regmeplease(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Table filter |
| Date: | 2007-11-21 21:52:54 |
| Message-ID: | 4744A8B6.6040700@joeconway.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Reg Me Please wrote:
> Il Wednesday 21 November 2007 20:22:46 Joe Conway ha scritto:
>> Reg Me Please wrote:
>>> The meaning is that an entity called by the value of "item" has a number
>>> of properties called by "property" with value "prop_value".
>>> So, for a single "item" there can be many different "property" each with
>>> its own value.
>>>
>>> A filter is a list of property values needed to qualify an entity as
>>> "good". An entity evaluates as good only when all property values in the
>>> filter match the ones associated to an item in t_data.
>>>
>>> What's missing to me is how to apply a filter to the t_data and get the
>>> list of the items that evaluate good.
>> I haven't played with it myself, but it seems to me that you could do
>> this with an inner join of two crosstabs -- one on t_data and one on the
>> filters (i.e. you join on the columns of the filter crosstab to the
>> matching ones in the t_data crosstab).
>>
>> Joe
>
> This is a good point.
> I just need to avoid doing crosstabs over a very large t_data: I fear it'd
> kill the application.
>
Yeah, I suspect as much too.
You might want to create a custom filter function based on the
crosstab_hash function in contrib/tablefunc. The basic elements are
there. Instead of building return tuples you could do the filtering and
return a boolean value for each row key or something like that.
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin Gainty | 2007-11-21 22:01:35 | Re: Read-only availability of a standby server? |
| Previous Message | Reg Me Please | 2007-11-21 20:44:22 | Re: Table filter |