Sorry, I forgot to send CC into pgsql-hackers.
On 29/6/21 13:23, Tomas Vondra wrote:
> Because sampling is fairly expensive, especially if you have to do it
> for large number of child relations. And you'd have to do that every
> time *any* child triggers autovacuum, pretty much. Merging the stats is
> way cheaper.
>
> See the other thread linked from the first message.
Maybe i couldn't describe my idea clearly.
The most commonly partitioning is used for large tables.
I suppose to store a sampling reservoir for each partition, replace on
update of statistics and merge to build statistics for parent table.
It can be spilled into tuplestore on a disk, or stored in a parent table.
In the case of complex inheritance we can store sampling reservoirs only
for leafs.
You can consider this idea as an imagination, but the merging statistics
approach has an extensibility problem on another types of statistics.
>
>
> On 6/29/21 9:01 AM, Andrey Lepikhov wrote:
>> On 30/3/21 03:51, Tomas Vondra wrote:
>>> Of course, that assumes the merge is cheaper than processing the list of
>>> statistics, but I find that plausible, especially the list needs to be
>>> processed multiple (e.g. when considering different join orders, filters
>>> and so on).
>> I think your approach have a chance. But I didn't understand: why do
>> you merge statistics? I think we could merge only samples of each
>> children and build statistics as usual.
>> Error of a sample merging procedure would be quite limited.
>>
>
--
regards,
Andrey Lepikhov
Postgres Professional