From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Yeb Havinga <y(dot)t(dot)havinga(at)mgrid(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Gist consistent and compression |
Date: | 2009-05-02 19:02:59 |
Message-ID: | E56421B9-93A5-493D-8F8F-BCFED042452C@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Le 1 mai 09 à 23:04, Yeb Havinga a écrit :
> An idea for possible improvement of query speed on gist indexes with
> a costly compression function. We have a gist index that uses a
> compressed internal datatype. The compression is with some cost (it
> involves a syscache lookup).
[...]
> small one. So it would make sense to add the caching to the gist
> support in the backend, instead of having to build one in the user
> defined functions gist functions for every datatype.
>
> Any thoughts?
It seems to me that what you're asking for is addressed indirectly in
the possibility to make your internal data type a full SQL visible
datatype. Then you store this new datatype directly in the table and
index that. Instead of converting from external to internal type at
consistent() time in a query, provide an implicit CAST for external to
internal for queries to "just work" without editing. The CAST will get
called once per literal in the query.
See prefix and the prefix_range datatype as an example of this:
http://blog.tapoueh.org/prefix.html
I'm not sure if the caching facility should be added to -core
PostgreSQL or not, I'm just proposing another way to solve your
problem without requiring it...
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-02 20:38:48 | Re: windows doesn't notice backend death |
Previous Message | Andrew Dunstan | 2009-05-02 18:56:56 | windows doesn't notice backend death |