|
96 | 96 |
|
97 | 97 |
|
98 | 98 |
|
| 99 | +From pgsql-hackers-owner+M67@postgresql.org Tue Oct 31 19:18:16 2000 |
| 100 | +Received: from mail.postgresql.org ([216.126.85.28]) |
| 101 | +by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA08916 |
| 102 | +for <pgman@candle.pha.pa.us>; Tue, 31 Oct 2000 19:18:15 -0500 (EST) |
| 103 | +Received: from mail.postgresql.org ([216.126.85.28]) |
| 104 | +by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eA10IOl60635; |
| 105 | +Tue, 31 Oct 2000 19:18:24 -0500 (EST) |
| 106 | +(envelope-from pgsql-hackers-owner+M67@postgresql.org) |
| 107 | +Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4]) |
| 108 | +by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eA10H8l60400 |
| 109 | +for <pgsql-hackers@postgresql.org>; Tue, 31 Oct 2000 19:17:08 -0500 (EST) |
| 110 | +(envelope-from zakkr@zf.jcu.cz) |
| 111 | +Received: from localhost (zakkr@localhost) |
| 112 | +by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id BAA32036; |
| 113 | +Wed, 1 Nov 2000 01:16:42 +0100 |
| 114 | +Date: Wed, 1 Nov 2000 01:16:42 +0100 (CET) |
| 115 | +From: Karel Zak <zakkr@zf.jcu.cz> |
| 116 | +To: Alfred Perlstein <bright@wintelcom.net> |
| 117 | +cc: pgsql-hackers@postgresql.org |
| 118 | +Subject: Re: [HACKERS] Query cache import? |
| 119 | +In-Reply-To: <20001031151144.F22110@fw.wintelcom.net> |
| 120 | +Message-ID: <Pine.LNX.3.96.1001101005110.31713B-100000@ara.zf.jcu.cz> |
| 121 | +MIME-Version: 1.0 |
| 122 | +Content-Type: TEXT/PLAIN; charset=US-ASCII |
| 123 | +Precedence: bulk |
| 124 | +Sender: pgsql-hackers-owner@postgresql.org |
| 125 | +Status: OR |
| 126 | + |
| 127 | + |
| 128 | +On Tue, 31 Oct 2000, Alfred Perlstein wrote: |
| 129 | + |
| 130 | +> I never saw much traffic regarding Karel's work on making stored |
| 131 | +> proceedures: |
| 132 | +> |
| 133 | +> http://people.freebsd.org/~alfred/karel-pgsql.txt |
| 134 | +> |
| 135 | +> What happened with this? It looked pretty interesting. :( |
| 136 | + |
| 137 | + It's probably a little about me :-) ... well, |
| 138 | + |
| 139 | + My query cache is in usable state and it's efficient for all |
| 140 | +things those motivate me to work on this. |
| 141 | + |
| 142 | + some basic features: |
| 143 | + |
| 144 | +- share parsed plans between backends in shared memory |
| 145 | +- store plans to private backend hash table |
| 146 | +- use parameters for stored queries |
| 147 | +- better design for SPI |
| 148 | +- memory usage for saved plans |
| 149 | +- save plans "by key" |
| 150 | + |
| 151 | + |
| 152 | + The current query cache code depend on 7.1 memory management. After |
| 153 | +official 7.1 release I prepare patch with query cache+SPI (if not |
| 154 | +hit me over head, please ..) |
| 155 | + |
| 156 | + All what will doing next time not depend on me, *it's on code developers*. |
| 157 | + |
| 158 | + For example Jan has interesting idea about caching all plans which |
| 159 | +processing backend. But it's far future and IMHO we must go by small |
| 160 | +steps to Oracle's funeral :-) |
| 161 | + |
| 162 | + If I need the query cache in the my work (typical for some web+pgsql) or |
| 163 | +will some public interest I will continue on this, if not I freeze it. |
| 164 | +(Exists more interesting work like http://mape.jcu.cz ... sorry of |
| 165 | +advertising :-) |
| 166 | + |
| 167 | +Karel |
| 168 | + |
| 169 | + |
| 170 | + |
| 171 | + |
| 172 | + |
| 173 | + |