| From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
|---|---|
| To: | Bear Giles <bgiles(at)coyotesong(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Cory Nemelka <cnemelka(at)gmail(dot)com>, Aldo Sarmiento <aldo(at)bigpurpledot(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Processing very large TEXT columns (300MB+) using C/libpq |
| Date: | 2017-10-20 18:05:46 |
| Message-ID: | CAEzk6fe8w+-MXxApaR5pAxCHmHRP=D2jgtBO0XwDu7Jew6aM=g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On 20 October 2017 at 18:52, Bear Giles <bgiles(at)coyotesong(dot)com> wrote:
> As an aside any halfway decent optimizer would realize that the results of
> strlen() are unchanging as long as the contents of what it's passed isn't
> modified. That's a common enough pattern that it should be checked.
>
IME this is a myth perpetuated by bad computer science lecturers who
haven't thought through the consequences of what they're saying. strlen()
can change because of changes inside the loop but also because of also
threads in the system; I've not yet seen a compiler optimise that away, and
neither should it, IMO.
G
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bear Giles | 2017-10-21 11:32:00 | Re: Processing very large TEXT columns (300MB+) using C/libpq |
| Previous Message | Bear Giles | 2017-10-20 17:52:19 | Re: Processing very large TEXT columns (300MB+) using C/libpq |