Re: Support loser tree for k-way merge - Mailing list pgsql-hackers

From cca5507
Subject Re: Support loser tree for k-way merge
Date
Msg-id tencent_6B00C6CE2E74AF50A01635C54AC600CFE705@qq.com
Whole thread Raw
In response to Re: Support loser tree for k-way merge  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
Hi,

Thank you for your reply.

> Can we drive the decision for what to do based on optimizer
> stats, i.e. n_distinct and row counts? Not sure what the calculation would
> be specifically, but something else to consider.
> 
> We can still provide the GUC to  override the optimizer decisions,
> but at least the optimizer, given up-to-date stats, may get it right most
> of the time.

That makes sense to me.

TODO
====
1) Consider optimizer statistics when deciding whether to use the heap or the loser tree.
2) Do we need a USEMEM() call to the array of losers?
3) Now the array length of losers is MAXORDER * 2, and in fact MAXORDER is enough, need some refactor of the code. (Is
itworth doing?)
 
4) Add more code comments and doc.

Help are welcome!

--
Regards,
ChangAo Chen

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: jian he
Date:
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part