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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_avd
Следующее
От: "Jeroen Habets"
Дата:
Сообщение: Patch AbstractJdbc1Statement.setBoolean support BIT and INTEGER columns