duckdb

破局OLAP困境：PostgreSQL集成列存储数据的终极方案——DuckDB FDW深度实践PostgreSQL作为经典的行存储数据库，在事务型（OLTP）场景中表现卓越，但面对海量列存储数据（如Parquet、ORC）的分析型（OLAP）需求时，常陷入性能瓶颈。本文先剖析PostgreSQL适配OLAP与列存储的核心必要性，系统对比aws_s3扩展、Citus列存、DuckDB FDW等主流方案的优劣，最终聚焦高性能方案DuckDB FDW，通过“电商用户行为分析”“政务数据跨源查询”“企业IOT设备监控”三大实战场景，提供从环境部署到查询优化的完整落地流程，为企业构建“事务+分析”一体化数据

将利用30行X算法求解数独的python程序转成DuckDB自定义函数并比较性能将利用DeepSeek辅助改造30行DLX求解数独python程序和调用python函数的不同方法效率对比测试的代码整合在一起

【DuckDB】探索函数调用新范式：点操作符链式调用在数据库操作的日常实践中，函数调用的简洁性与直观性直接影响着开发效率与代码可读性。DuckDB 提供的点操作符函数链式调用功能，为我们打开了全新的函数调用视角，让数据处理逻辑更加流畅自然。

【DuckDB】duckdb和postgresql对于unnest函数的区别在postgresql中，unnest函数用于解开数组类型的嵌套，能把一个数组变成多行，但不解开一行中的多个字段；当unnest处于from后面时，如果解开的一行有多个字段，同时也会解开成多个字段。也就是说，在pg中可以通过控制unnest在sql语句中的位置，来决定展开的层级。

DeepSeek对利用DuckDB求解Advent of Code 2021第9题“烟雾盆地”第二部分SQL的分析这是DBatUTuebingen发布的。源地址：https://github.com/DBatUTuebingen/Advent_of_Code

在postgres和duckdb中比较两个数组并只挑选不匹配的元素直接用-运算符是不行的, 网上用AI生成的文档很不负责地误导大家。duckdb 也会报错文档中有array_remove函数，但一次只能删除一个元素

在duckdb 递归CTE中实现深度优先搜索DFS原帖地址 https://github.com/duckdb/duckdb/discussions/15386

豆包解读论文：将具有分支和循环控制流的命令式程序转换为标准SQL1999的公共表表达式这是豆包对论文SQL Engines Excel at the Execution of Imperative Programs的总结

苏旭晖先生写的纯SQL求解Advent of Code 2025第9题最大矩形面积第2部分原贴地址，我把它改成了能在DuckDB运行，主要是把connect by level 改为 range函数

利用Duckdb求解Advent of Code 2025第9题最大矩形面积原题地址。第一问已知坐标x,y原点在左上角显示如下求以#为对角顶点的长方形面积最大值第二问已知直角非凸多边形的各顶点坐标（首尾相接），计算它中间以两个顶点为对角顶点的长方形面积最大值。比如

三种用SQL解决Advent of Code 2022第8题树顶木屋的比较和分析题目链接 1.张泽鹏先生的SQL, 处理带换行符的输入文件如果要处理不带换行符的文件，把matrix之前的改成如下，用row_number代替 generate_subscripts

利用Duckdb求解Advent of Code 2025第5题自助餐厅原题地址。 — 第 5 天：自助餐厅 — 当叉车打通墙壁时，精灵们高兴地发现，另一边确实有一个自助餐厅。

【DuckDB】活用marco以兼容GaussDB的SQL执行【DuckDB】活用marco以兼容GaussDB的SQL执行前文有提到，有些复杂的分析型SQL在DuckDB上执行会比GaussDB上快，但实际应用场景中，GaussDB有些函数在DuckDB上并不支持，因此有时候会需要修改GaussDB的SQL,但如果一个某些函数用得非常多，入参还不一样，无法简单替换，那么修改原SQL就会具有一些工作量。所以就会想到，我能不能在不修改DuckDB源码的情况下，给DuckDB添加这些函数支持呢？答案是的确可以,DuckDB虽然不具备创建复杂的PLSQL函数的能力，但

使用DuckDB SQL求解Advent of Code 2024第9题磁盘碎片整理原题地址 https://adventofcode.com/2024/day/9再次按下按钮后，你们来到了某个友好端足类动物熟悉的走廊里！好在你们每个人都莫名其妙地拥有了一艘个人迷你潜水艇。历史学家们喷着水流去寻找首领，主要是通过直接撞向墙壁的方式。

利用DuckDB列表一句SQL输出乘法口诀表先热身，用生成式列表输出几行不同长度的序列，从默认的标题列可知，生成式列表后台实际调用了list_apply函数。

调用python函数的不同方法效率对比测试方法1：用注册DuckDB自定义函数的方法, 我用的是1.3.2版的DuckDB, 在create_function时总是报错，

改写ITPUB newkid的求解数独DuckDB SQL为Clickhouse格式主要包括 1.将CTE表d改写成非递归形式，其实d单独执行是可以的，不知何故，一个SQL中有两个递归时，非要说它不是递归的 2.将整除符号//改为Floor(除法)，//在Clickhouse中表示注释 3.改写左移位运算符<<为bitShiftLeft，并强制转换参数为Int128和Int。 4.有的子查询表没有别名，用set joined_subquery_requires_alias = 0;避免报错，加上别名更保险 5.按位与&符号改为bitAnd函数

把ITPUB newkid先生编写的Oracle语法数独求解SQL改写成DuckDB原答案是用绑定变量的，为了改写成表的列，增加了ANY_VALUE函数。然后为了存下整个表格81格点的位置，用了hugeint。

利用短整数类型和部分字符串优化DuckDB利用数组求解数独SQL与利用定长字符串版本相比，利用整数数组的速度略慢，这是因为数组是复杂数据结构，有开销，这个开销抵消了字符串转整数的开销。因此，它还有几处细节可以优化。 1.存储二进制位状态的rows, cols, boxes数组都保存了大整数，而在每个递归步骤都要保存当前的状态，多用了几倍的空间，考虑每个二进制不超过512，可以用转成smallintl类型来优化。实测计算只有17个已知数的最小数独，定长字符串版本用时3.048秒，大整数数组用时4.686 秒，短整数数组用时3.212秒。 2.每步用instr从字符串

利用DeepSeek优化SQLite求解数独SQL用于DuckDBSQLite文档中提供了一个求解数独SQL，我把它用于一个高难度的数独题： '.....1..7....6..2.8..9..3...954....3..3...4..4......8......7..6.1..2....5..3..9..'，结果用时10秒，同样的语句，只把除法符号/替换成整除符号//，在DuckDB中运行反而更慢，要13秒，单线程和多线程的结果都是差不多时间。