| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | "lkcl (dot)" <luke(dot)leighton(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [feature] cached index to speed up specific queries on extremely large data sets |
| Date: | 2014-04-11 12:26:57 |
| Message-ID: | 5347DF91.8040000@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/11/2014 03:20 PM, lkcl . wrote:
> so i had an idea. there already exists the concept of indexes. there
> already exists the concept of "cached queries". question: would it be
> practical to*merge* those two concepts such that specific queries
> could be*updated* as new records are added, such that when the query
> is called again it answers basically pretty much immediately? let us
> assume that performance degradation on "update" (given that indexes
> already exist and are required to be updated) is acceptable.
I think you just described materialized views. The built-in materialized
views in PostgreSQL are not updated immediately as the tables are
modified, but it's entirely possible to roll your own using views and
triggers. There are a few links on the PostgreSQL wiki, in the "Versions
before 9.3" section: https://wiki.postgresql.org/wiki/Materialized_Views.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-04-11 12:28:55 | Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0 |
| Previous Message | lkcl . | 2014-04-11 12:20:06 | [feature] cached index to speed up specific queries on extremely large data sets |