On Fri, Dec 1, 2017 at 4:06 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: >>> I agree with these thoughts in general, but I'm not quite sure >>> what is your conclusion regarding the patch. >> >> I have not reached one. Sometimes I like to discuss problems before >> deciding what I think. :-) > > That's lame! Let's make decisions without discussion ;-)
Oh, right. What was I thinking? >> It does seem to me that the patch may be aiming at a relatively narrow >> target in a fairly large problem space, but I don't know whether to >> label that as short-sightedness or prudent incrementalism. > > I don't know either. I don't think people will start switching their > text columns to lz4 just because they can, or because they get 4% space > reduction compared to pglz. Honestly, if we can give everybody a 4% space reduction by switching to lz4, I think that's totally worth doing -- but let's not make people choose it, let's make it the default going forward, and keep pglz support around so we don't break pg_upgrade compatibility (and so people can continue to choose it if for some reason it works better in their use case). That kind of improvement is nothing special in a specific workload, but TOAST is a pretty general-purpose mechanism. I have become, through a few bitter experiences, a strong believer in the value of trying to reduce our on-disk footprint, and knocking 4% off the size of every TOAST table in the world does not sound worthless to me -- even though context-aware compression can doubtless do a lot better. > But the ability to build per-column dictionaries seems quite powerful, I > guess. And I don't think that can be easily built directly into JSONB, > because we don't have a way to provide information about the column > (i.e. how would you fetch the correct dictionary?). That's definitely a problem, but I think we should mull it over a bit more before giving up. I have a few thoughts, but the part of my life that doesn't happen on the PostgreSQL mailing list precludes expounding on them right this minute. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
