Hi all, I'm going to start a personal branch with a PostgreSQL full-text search functionality for the djangoproject.com website.
I would to sprint on it during the next EuroPython 2017 in Rimini and I've added the Sprint proposal in the wiki: https://wiki.python.org/moin/EuroPython2017/Sprints I'll be there on Saturday 15/07/0217 and if someone would to join me I would be happy. -- Paolo On Mon, May 8, 2017 at 6:28 PM, Tim Graham <[email protected]> wrote: > I agree that eliminating elasticsearch could be a simplification win from > a maintenance perspective. For example, I spent some hours a few months ago > debugging a problem with a new version of elasticsearch that caused our > cluster to run out of memory and lock up every ~24 hours. Also, not having > to set up elasticsearch to contribute to the docs.djangoproject.com > search is nice. On the other hand, I wonder how moving the search load to > PostgreSQL will effect server load, disk usage, etc. > > On Monday, May 8, 2017 at 11:14:58 AM UTC-4, Tobias McNulty wrote: >> >> I'm no FTS expert, but based just on the facts raised in this thread, if >> using Postgres FTS >> >> 1. would not break existing nor potential search needs (in fact it >> might expand the functionality available) and >> 2. would allow eliminating an entire service from the infrastructure >> >> that seems like a net win to me and as such at least worth exploring >> further. That is not to say I think we should commit to switching, but if >> we have volunteers who are excited to flesh out this proposal with some >> code and understand there's no guarantee it will actually get merged, I >> don't (yet) see a reason to say no. >> >> On Mon, May 8, 2017 at 10:07 AM, Marc Tamlyn <[email protected]> wrote: >> >>> Yes, don't need that sorry. >>> >>> On 8 May 2017 at 14:40, Adam Johnson <[email protected]> wrote: >>> >>>> I'm pretty sure our search requirements on dp.com need that, >>>> >>>> >>>> s/need/don't need/ ? 😉 >>>> >>>> On 8 May 2017 at 13:59, Marc Tamlyn <[email protected]> wrote: >>>> >>>>> I'm not sure I see the benefit here. The strength and purpose of >>>>> postgres FTS is that you can combine some FTS behaviour with some >>>>> relational queries easily at the same time. I'm pretty sure our search >>>>> requirements on dp.com need that, so using a dedicated search >>>>> provider is a better option. >>>>> >>>>> On 7 May 2017 at 13:22, Florian Apolloner <[email protected]> wrote: >>>>> >>>>>> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote: >>>>>>> >>>>>>> I guess we'd also have the benefit of not having to keep >>>>>>> elasticsearch running. >>>>>>> >>>>>> >>>>>> On the contrary, putting it into postgres means we have to care about >>>>>> it. Putting it into Elasticsearch means we can let our hoster take care >>>>>> about that. >>>>>> >>>>>> >>>>>>> But I'm afraid I'm not familiar with Postgres. Is the FTS in >>>>>>> Postgres mostly equivalent to ES, or will some kinds of search queries >>>>>>> be >>>>>>> affected? >>>>>>> >>>>>> >>>>>> For the queries we use I think we can get pretty much equivalent >>>>>> results. >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx4s_G7SkH6OhLh6Ve48RptGa1RuFDN6gHGfEFrYZYKT5g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
