Re: patch: SQL/MED(FDW) DDL
От | Robert Haas |
---|---|
Тема | Re: patch: SQL/MED(FDW) DDL |
Дата | |
Msg-id | AANLkTikSDLeoyynDTobVvKocDv25gQaC0Wjk_DmUme8a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch: SQL/MED(FDW) DDL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: patch: SQL/MED(FDW) DDL
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
On Tue, Oct 5, 2010 at 12:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Oct 5, 2010 at 11:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> IMO this is a *clear* case of premature optimization being the root of >>> all evil. We should get it working first and then see what needs to be >>> optimized by measuring, rather than guessing in a vacuum. > >> I have no problem with punting the issue of remote statistics to some >> time in the future. But I don't think we should have a half-baked >> implementation of remote statistics. We should either do it right >> (doing such testing as is necessary to establish what that means) or >> not do it at all. Frankly, if we could get from where we are today to >> a workable implementation of this technology for CSV files in time for >> 9.1, I think that would be an impressive accomplishment. Making it >> work for more complicated cases is almost certainly material for 9.2, >> 9.3, 9.4, and maybe further out than that. > > I quite agree that it's going to take multiple release cycles to have > a really impressive version of SQL/MED. What I'm saying is that caching > remote statistics is several versions out in my view of the world, and > designing support for it shouldn't be happening now. Fair enough. > Maybe we ought to take a step back and discuss what the development plan > ought to be, before we spend more time on details like this. Good idea. > My idea of > a good development process would involve working in parallel on at least > two FDW adapters, so that we don't find we've skewed the API design to > meet the needs of just one adapter. Probably a remote-PG adapter and a > local-CSV-file adapter would be a good combination. I don't have any > clear idea of how soon we might expect to see how much functionality, > though. Thoughts? I'm somewhat afraid that a remote-PG adapter will turn into a can of worms. If we give up on remote statistics, does that mean we're also giving up on index use on the remote side? I fear that we'll end up crafting partial solutions that will only end up getting thrown away, but after a lot of work has been invested in them. I wonder if we should focus on first efforts on really simple cases like CSV files (as you mentioned) and perhaps something like memcached, which has different properties than a CSV file, but extremely simple ones. I think it's inevitable that the API is going to get more complicated from release to release and probably not in backward-compatible ways; I think it's too early to be worried about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: