From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | twoflower <standa(dot)kurik(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Emulating flexible regex replace |
Date: | 2014-10-25 09:31:48 |
Message-ID: | CA+bJJbwyUGxxtabc3J0rTwYOKXNZ+bkbz2i1OO1Z3Yk9pbXZ9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi:
On Fri, Oct 24, 2014 at 6:13 PM, twoflower <standa(dot)kurik(at)gmail(dot)com> wrote:
....
> It works very vell. However, I am not completely satisfied with i as it's
> unnecessarily loading larger data set than it absolutely must. Besides, I'd
> also like to get some experience in DB programming. That's why the PL/Perl
> way seems pretty attractive to me.
>
Try it them. But bear in mind you are not *unnecessarily* loading the data
set, the server will need to load it to apply the plperl filters, you will
just avoid loading it in the client and transmitting it. You are making a
trade off, a design decission. You are trading some network and client cpu
usage for some server cpu usage and coding complexity. The tricky part is
the the coding complexity, which needs a lot of resources you may never
recover. Part of the experience in DB programming is knowing what NOT to do
in the database, so coding this will be good, the worst thing that could
happen is you do it and then drop it after learning one thing.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2014-10-25 09:55:43 | Re: Non-capturing expressions |
Previous Message | Thom Brown | 2014-10-25 09:24:29 | Non-capturing expressions |