Re: pg_avd
От | Matthew T. O'Connor |
---|---|
Тема | Re: pg_avd |
Дата | |
Msg-id | 1045670790.13438.95.camel@zeutrh80 обсуждение исходный текст |
Ответ на | Re: pg_avd (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_avd
|
Список | pgsql-patches |
On Wed, 2003-02-19 at 10:11, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Matthew T. O'Connor writes: > >> I think it's a question of, is this solution one that we want to keep > >> for a while, or do we want a different implementation of AVD, perhaps > >> something built into the backend that could take advantage of the FSM > >> also. > > > To me it seems that this would be much better if kept inside the server. > > I agree, it seems like a server-side implementation would be the only > credible way to go for a production-grade version of this feature. > > But I don't see anything wrong with building a client-side prototype, > which is what pg_avd looks like from here. (Unless the client is > contorted by not being able to get at things it needs.) I don't think pg_avd is contorted, but it is limited to the data published by the stats system, so there is no FSM etc... I also think it would probably be better in the backend, I just wasn't sure if the additional complexity was worth it. The primary advantage of a client side implementation is simplicity. That said, I originally tried to do this in the backend, but found the task too daunting for me and gave up. When Shridhar started some work on a client side version I decided to run with that and see how far I could get. Question: Should I keep working on pg_avd for contrib inclusion in 7.4, or should I try again on a backend implementation that might be less likely to get into 7.4?
В списке pgsql-patches по дате отправления: