On 11/11/24 17:49, Ba Jinsheng wrote:
>It is all the time a challenge for PostgreSQL to estimate such a filter
>because of absent information on joint column distribution.
>Can you research this way by building extended statistics on these
>clauses? It could move the plan to the more optimal
>> The default configurations of PostgreSQL incur the error: "ERROR: could not
>> resize shared memory segment "/PostgreSQL.3539600020" to 2097152 bytes: No
>> space left on device"
>No comment on your optimiser experiments for now, but for this error:
>it reminds me of a low/default --shm-siz
>It is all the time a challenge for PostgreSQL to estimate such a filter
>because of absent information on joint column distribution.
>Can you research this way by building extended statistics on these
>clauses? It could move the plan to the more optimal direction.
Thanks a lot for your effort to
On 11/11/24 02:35, Ba Jinsheng wrote:
Hi all,
Please see this case:
Query 4 on TPC-DS benchmark:
Thank you for interesting example!
Looking into explains I see two sortings:
-> Sort (cost=794037.94..794037.95 rows=1 width=132)
(actual time=3024403.310..3024403.313 rows=8 loops=1)
-> Sor
On 10.11.2024 23:16, Alena Rybakina wrote:
Hi!
On 10.11.2024 22:35, Ba Jinsheng wrote:
Hi all,
Please see this case:
Query 4 on TPC-DS benchmark:
with year_total as (
select c_customer_id customer_id
,c_first_name customer_first_name
,c_last_name customer_last_name
,c
Hi!
On 10.11.2024 22:35, Ba Jinsheng wrote:
Hi all,
Please see this case:
Query 4 on TPC-DS benchmark:
with year_total as (
select c_customer_id customer_id
,c_first_name customer_first_name
,c_last_name customer_last_name
,c_preferred_cust_flag customer_preferred_cust_
On Mon, Nov 11, 2024 at 8:36 AM Ba Jinsheng wrote:
> The default configurations of PostgreSQL incur the error: "ERROR: could not
> resize shared memory segment "/PostgreSQL.3539600020" to 2097152 bytes: No
> space left on device"
No comment on your optimiser experiments for now, but for this e
