小编len*_*len的帖子

我们为 CloudWatch 日志组配置了指标过滤器，该组为我们的某个流程收集数据。

最初，我们只有一个与日志组的日志流关联的 ec2 实例。从日志中检索到的数据很好地显示在图表中。

但是，我们希望有多个实例连接到同一日志流或日志组。当我们为日志组配置另一个实例时，图表变得损坏：

断图

根据我们的观察，看起来只有当这些点是从最新实例派生的连续数据时，这些点才会连接。否则，它只是表明了一个观点。

显示的所有数据仍然正确。只是它们并没有全部连接起来。有没有办法让所有点都连接起来？

保存卡以备将来付款时是否可以使用3D Secure？

从Stripe的文档中，https://stripe.com/docs/sources/three-d-secure。这似乎是这样做的方法。

但是根据文档，不再建议使用而是使用PaymentIntents：

不再建议使用此API。如果您希望使用3D Secure，我们强烈建议您采用我们的新付款API PaymentIntents。

因此，有没有办法使用PaymentIntents（以利用3D安全）仅保存卡而无需立即付款？

这篇文章（https://vladmihalcea.com/hibernate-hidden-gem-the-pooled-lo-optimizer/）给出了差异一个很好的解释hilo，pooled并pooled-lo进行序列发生器优化。它还解释了从休眠 5 开始，pooled如果分配大小大于 1 ，则使用优化器作为默认值。

使用pooled-lo优化器与默认pooled优化器相比有优势吗？我确实注意到 for pooled，有一个额外的数据库调用来获取“next hi”值（我认为是因为计算的工作方式）。除此之外，我不确定两者之间的性能是否存在差异。

为什么pooled用作默认值？使用 是否有显着优势pooled-lo？

我在postgres数据库中删除了大量的行,稍后进行了真空分析.

我注意到AWS RDS控制台中的磁盘使用量没有太大变化.

尝试运行查询,基于表大小没有移动太多.

SELECT *, pg_size_pretty(total_bytes) AS total
    , pg_size_pretty(index_bytes) AS INDEX
    , pg_size_pretty(toast_bytes) AS toast
    , pg_size_pretty(table_bytes) AS TABLE
  FROM (
  SELECT *, total_bytes-index_bytes-COALESCE(toast_bytes,0) AS table_bytes FROM (
      SELECT c.oid,nspname AS table_schema, relname AS TABLE_NAME
              , c.reltuples AS row_estimate
              , pg_total_relation_size(c.oid) AS total_bytes
              , pg_indexes_size(c.oid) AS index_bytes
              , pg_total_relation_size(reltoastrelid) AS toast_bytes
          FROM pg_class c
          LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
          WHERE relkind = 'r'
  ) a
) a order by total_bytes desc;

这是正常的吗？或者磁盘空间根本没有被回收？