[Bucardo-general] [SOLVED] b5 / pg84 : "arguments of row IN must all be row expressions"

Greg Sabino Mullane greg at endpoint.com
Wed Sep 26 03:41:10 UTC 2012


> 1. I can't see any difference between the PGIN block (8087-8108) and
> the "vanilla" IN block (8025-8046), save the condition in the elsif.
> Am I missing something screamingly obvious (witness my confessed
> present lack of brain), or was this something that was previously
> different, or planned to be different later?  If not, should those
> blocks be consolidated?

I think they were different and then melded to the same code. Yes, they 
can be consolidated. A good chance to exercise your commit bit. :)

> 2. If the motivation for using a limited chunk size for IN() blocks is
> that they're known to lose performance-wise in postgres when they get
> very large, might it be useful to refactor the IN() list into a DELETE
> ... USING (VAUES...)?  E.g.:
> 
> DELETE FROM schema.table st
> USING (VALUES(v1),(v2),(v3)...(vN)) deletelist(val)
> WHERE st.pkey = val;
> 
> I've found that refactoring IN() lists (especially large such) into
> joins against VALUES clauses is often a significant performance win.

Sure, give it a whirl. However, keep three things in mind:

1) The rationale was not speed so much as running into stack size 
limits, e.g. the physical length of the SQL statement.

2) Make sure you determine which version started allowing that syntax.

3) Can that work for multi-column pks?


-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20120925/512de2d0/attachment.sig>


More information about the Bucardo-general mailing list