3 ms·

> I'm not sure what this means. Do you have a reference? https://www.postgresql.org/docs/9.3/postgres-fdw.html https://www.postgresql.org/docs/9.3/postgres-fdw

> I'm not sure what this means. Do you have a reference? https://www.postgresql.org/docs/9.3/postgres-fdw.html https://www.postgresql.org/docs/9.3/postgres-fdw.html https://www.percona.com/blog/2018/08/21/foreign-data-wrappers-postgresql-postgres_fdw/ https://www.percona.com/blog/2018/08/21/foreign-data-wrapper... https://pgxn.org/tag/foreign%20data%20wrapper/ https://pgxn.org/tag/foreign%20data%20wrapper/ >It seems pretty clear that building an efficient query plan depends on having access to the internals of any entities referenced by the query. Most query planners are based on table statistics so what you need to know are the size of the table, and the correlation of the actual data, but they don't need to know whether it's a BTree, LSM, epsilon tree, etc. This can be measured without knowing the underlying implementation. Postgres query planning statistics: https://www.postgresql.org/docs/current/view-pg-stats.html https://www.postgresql.org/docs/current/view-pg-stats.html

naasking 8y ago
Firstly, try writing a query planner when some of the columns being joined are hidden or inaccessible (which is what I described in my post). For instance, suppose it's a dynamically computed property whose computation you don't have access to. That's specifically what the tension between encapsulation and declarative programming means. Secondly, it seems clear that "table statistics" are a weakening of encapsulation properties. Perhaps they are the minimal weakening needed to provide efficient query planning, but it still justifies the claim that encapsulation and declarativity are in tension.
- fnord123 8y ago
  >it seems clear that "table statistics" are a weakening of encapsulation properties. I don't have the original source of the Ullman comments so I don't know the definitions he's using to make his assertion. So unfortunately I'm speaking a bit out of ignorance about precisely what he meant. I can't really say whether or not table statistics is a weakening of what he intended.

naasking 8y ago

Firstly, try writing a query planner when some of the columns being joined are hidden or inaccessible (which is what I described in my post). For instance, suppose it's a dynamically computed property whose computation you don't have access to. That's specifically what the tension between encapsulation and declarative programming means. Secondly, it seems clear that "table statistics" are a weakening of encapsulation properties. Perhaps they are the minimal weakening needed to provide efficient query planning, but it still justifies the claim that encapsulation and declarativity are in tension.

fnord123 8y ago
>it seems clear that "table statistics" are a weakening of encapsulation properties. I don't have the original source of the Ullman comments so I don't know the definitions he's using to make his assertion. So unfortunately I'm speaking a bit out of ignorance about precisely what he meant. I can't really say whether or not table statistics is a weakening of what he intended.