Re: Processing long AND/OR lists

My last email was written before reading this. A few episodes of 24
occurred between writing and sending that email.

Added slony1-hackers, but didn't remove pgsql-hackers. Feel free to exclude
pgsql lists, as this branch of conversation seems to be more Slony related
than Postgres.

On Sun, May 26, 2013 at 10:59 PM, Christopher Browne <cbbrowne(at)gmail(dot)com>wrote:

>
> In Slony 2.1, the issue re-emerged because the ordering of the "action id"
> values was lost; the query had previously been implicitly forcing them into
> order; we had to add an "ORDER BY" clause, to make the "compressor" work
> again.
>
> http://git.postgresql.org/gitweb/?p=slony1-engine.git;a=blobdiff;f=src/slon/remote_worker.c;h=b1f48043f8e25b4a74a392b0dbceeae8f3e18c27;hp=7fbf67c16f97cb7c3f209cf3be903ea52c4490a9;hb=c4ac435308a78a2db63bf267d401d842c169e87d;hpb=d4612aab78bac5a9836e3e2425c403878f7091c8
>
>
Commit log says it was fixed between 2.1.2, but from the Slony logs at the
time, the version in use was 2.1.2. So

> Joking about "640K" aside, it doesn't seem reasonable to expect a truly
> enormous query as is generated by the broken forms of this logic to turn
> out happily. I'd rather fix Slony (as done in the above patch).
>

Yes, by all means, fix the application, but that doesn't preclude the
argument that the database should be a bit more smarter and efficient,
especially if it is easy to do.

Best regards,
--
Gurjeet Singh

http://gurjeet.singh.im/

EnterpriseDB Inc.