Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mCzbS-0001dl-SI for pgsql-performance@arkaria.postgresql.org; Mon, 09 Aug 2021 07:21:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mCzbR-0004aY-8H for pgsql-performance@arkaria.postgresql.org; Mon, 09 Aug 2021 07:21:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mCfLT-0004sT-SO for pgsql-performance@lists.postgresql.org; Sun, 08 Aug 2021 09:43:52 +0000 Received: from sonic302-21.consmr.mail.ne1.yahoo.com ([66.163.186.147]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mCfLO-00081j-O5 for pgsql-performance@postgresql.org; Sun, 08 Aug 2021 09:43:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1628415825; bh=WiHDpcC7JjzcPwLYpO6CIcOdECnoN33904Hrebs9rW8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=N0w5pNejJ+AbcMaEwUnNpTbi+9hmPO4h/44VdQzL+9/0r55uCaBU7Y3RKv6Ed1nfz9uPn8r0tXWHBUUo1mbQWcWgcLsCeWNiHedDbx5+XfQwkNWL4R7ZWEMErzLJeX+uhQKX3yqJhtwNOl8YlXhYFarafnQpfA4e09rfaaZ0sMRqyImKhYPPI1jxrtpzCKqI+8dMYAkEsU1cY+ZkvuZ6W/NpAMl+leFHEOrF1rfLEt3m+dW77h8Rg9ldn+ibHioOIomU6OOkf7pvr7qScl7i4KM2QZr+C0/y2b635+bvpnFWEGvlYWpYKD/aD3jYJIXCO8zbkHjqUFFTgqad+MnHLg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1628415825; bh=9aIULRJ8iwrRXi32phd+X2WE4NIUA5gQ+nAdAIqPJms=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=SeKxrQ+i0dUoXUzLaW7tDm9gd6MP7kxvByutaPNwL9+Jl8ehQZwb6w3LjcrNObfIPhM6yxx9dJP/3gI8YKuDF9zMbeKNyc/7YdXSQc+LUtRAn541Ud6binZ/LHZRqi9qfmCY0FMGCnFpPUbY79q8nKyV9TSYT8aCF4nN/Hy9dC6PBgWAsQdTg99MyrILMp3xofvD7tBUBG7nzpudI2qVmPXpzOTdgz68vK3vGYhF7PPU8WdAmNZ9rRW+ct7TD+OdLBFb0UmIh9NqlC5FzJckRzXsKaqScOPma9EtnNJMmgMFDubvOwocEroVgxJspZYWq7z7L7iH+R48ugb98ORAMA== X-YMail-OSG: w0f9BcEVM1lbUecydTUYiXEV0CNkpvigSZ52D_qDX7cAweX0K3519pQmrwOPnks ZOm51nIjULTA4Z03mOCLGI9ViHHV_dibVMlDMIKhxsQhlluytOVYmbqBqHlIJHm8lUF29bUoJblV ZXoBYOCuC.u1QL71tRQQX7RydV5NSPoh2FJU6.UBlBWR7nBGAA.6uxMdauSu56rjVcG.gP4QSSGR T0qsjjTnuKiDOA0Zla3hbku0ACfAHvzkFGT1.H5hWEAoOLf0eZqNllkz7eLxItGhJyKnmjYg1Vuk zSlXn_nnaFWJL4Sb5ft0HsHnoOK1JfvL28Wa.tTiHBaxmEyNvdS14OzFxxsPJRiROW2FWaAjAIgs grPYTJ5IcTbqLu88XUDDgXr7i8Dyi1zkU_6xk8zu2q4vj8b6bDzjt6j.u8q535lGM_dFHiLs5QmX XdtNeiid3tjiErdmqb_1FNZX3Rd8VWwbPFZB16IrDgsO4OdX_QF5AbmVZT5A4Kd3nDD8tViAfi_y oE1UlkR24sTyv0vNkcc0rfbprDmU2HgKjw0OxjLNqc3jjv7a1aiiBCEWslUmEivcai2WPGjpc2ut v8gvs2kLQYRxvYGXFIbQLUeS5MN1IjxLJ5.wYdCvm1e4aS060_Hj_RlsY.EAUmhLkj_lp_w7K7e0 SdyoqeGk8qi52E8w7uWXMNtcRdqxktVQ8i0fzpCCN6fVCA1AoXPxjgkXBClXonEUqhbrbY.UtSL2 sqBEUmfAgLizAchNP46LWVSXT1j5LxdMd1h6JJLihdXby_qQe6fCKwBwJQdb_zoahmwZwnCQ9N8K 3GW7o6W8QAUCb33R09z3FY1Lsl4IumCeIDjkqcu3D5FlFb0orXPaCjvi6hWQ74Z7vTD74sly35Wd mp_NeMe3t_2EwnC7P_w1_S8EdOC5DuPI2ECBtm6qIbkQsb7qfKR7aZUuNfoyeTAvHBTZHIB0mJRD sLJtgZSTq62o8tyWNNt9yLnvOM2CyJ65orQ7IjvlFVOioVJC9iCObeK1EJimp7HWIhhX76DaTplu sW1XT8tGOoqKxi5b0usO_toZu1GhzdeAXWWmyVh44kSZW8a1qmbJxPBj8YargWB0.6Nu67dS3gDo aT5nXIWXFdQXT97MfsMBHDEugCPqL_QFgXLgirP8E7Qz_UC2GxdbggBlS3kaBcbLqZfKkjMf_TKK uVocnF2wHJF5N1GsE2Vzk9bF0XqKDQiAIyf3N.vELXr4c4LgP4PD78fT.vfEi7zLY7bpyBPpOqit 501CsHwJbScvKlOLfdcIRGJAKcbRDxnjjvcD0ALI6DmUUaclbCrja0fUae7uaqXhFzOao5Gbqmxh ETRa6YL1Axi5hRvNnrRNmn7wnf5JusKzmtvfDTGGR7gjtVnGBfGcPKJ8DeWSOKVZhSNnmGql73KG gGFnmpz2B0rNNNMFfJtx2HhwD5m_hhR3tbrOTWvOICoehUsb6Qbe4Uv9TFENxL65j4JJ5M1VbMxc jpaYDdEhkUROv18un5jfq.tU5J5s6dvq8YGP_fxpNtFsL5780Tt6N1WbCo5LEuarqpUl44CqEg0e vDt7M4Ap.nHZVGevr48Vg.zYzom.RBBaQU4cnhe2YpJQArT_zsKhcIK0A4tHzidGG1u8kjXuiN.p 1it0o1TmW7ohP5HKNOGWYOXYIebNxpE7E1Cg_HyKvPl9tSedHmUX95iCsH3bsAes5T5NkeCFpfhY tWiNg5C5tO9KE7IV7Vpf1oCuBkvHpKQSTFAZ9DCaz1nb77hrIui33zY0f3hy.Pd.MUhBHRXLRrw7 Yy76AVJiPxKMT1trfA3XDtZl6nYvkcgagWCMOCUrN.ayaA3KivGpMhCU1KxPxKvj0r3hS3bckv81 0ZalSIwGgQCegoHz5G529iSwDhlpQco_svBhqfQcW420R.lHuSxBLisvASMRj4ecN4qcJILz5XMI QYwnQlFyZEM.25hFtwXSMlV8Dg1hCDlxzmFW6gkOQOoJiVhx5m2auEIRYM3hvWib6gbjNvNAmzQE Thdf7KLMhSECRcCxSIokixC.GHQes5Umw1jUHyNLRf3DTnEcXfmXAbovq2dpamTqvf5AeRASLOCx 0xELRf2rq2FVuH3sxdTnxFxRtkS3aIzkt84tK239XnWFJ3QpZZSyw0XgVCOMYO6YjHayI7R2597o Zud8aS9NmW1xZQzQIpOFH.edgILnIDX3kCyMYdzRC0pUoZP7aOjgZZ_YQ1187Di6AvgrTN63X9LE KtRQAHjjJgW3t7AxUvm05VRs2AqVR8N8en.Wv2moxmlMnG3KC0bHeLBIjTs1fPwUqtqOXZ.43Rr9 KPHzV7cu.vvD6t5ea8lQ6zg1v0N0OypltqWl3fplhQsuVh4q.C33BSGPcCX6acn39br_D9LvPvtE KQjY3j0BAQvyXywXr6yEiPQk7slTDdW_xXIatUQCOrBN7J_g6SNKFnFpvMLsfpb3v6W5FCP5.uoz XyknIAr2xoyzpsDy5ZZIWOXpXQz2TtDZ2RSN3f_8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sun, 8 Aug 2021 09:43:45 +0000 Date: Sun, 8 Aug 2021 09:43:40 +0000 (UTC) From: Alex To: Justin Pryzby Cc: "pgsql-performance@postgresql.org" Message-ID: <957401570.740502.1628415820928@mail.yahoo.com> In-Reply-To: <20210808003528.GZ10479@telsasoft.com> References: <1557921338.669347.1628364925994.ref@mail.yahoo.com> <1557921338.669347.1628364925994@mail.yahoo.com> <20210808003528.GZ10479@telsasoft.com> Subject: Re: Slow query because lexeme index not used MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_740501_1260519995.1628415820925" X-Mailer: WebService/1.1.18796 YMailNorrin Content-Length: 17583 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_740501_1260519995.1628415820925 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Could you show the table stats for product.id ?=C2=A0 In particular its "correlation". =C2=A0frac_mcv | tablename | attname | inherited | null_frac | n_distinct |= n_mcv | n_hist | correlation ----------+-----------+---------+-----------+-----------+------------+-----= --+--------+------------- =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | product=C2=A0=C2= =A0 | id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | f=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -1 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 101 |=C2=A0=C2=A0 0.3857521 > How large is shared_buffers ?256MB > Does the query plan improve if you increase work_mem ?No, same plan. > Maybe you could encourage scanning in order of product_property.product..= .Clustering "product_property_default" on "product_property_default_product= _idx" followed by analyze, does not change the plan. > Or you could write the query with a temp table:Creating the temp table "p= roduct_ids" changes the plan to use lexeme_idx: https://explain.dalibo.com/= plan/19h But I prefer not to use an extra step for my query. > Maybe it would help to create stats on "first" and "meaning"... I've played around with statistics, and increasing column stats with the ex= tended statistics improve the planner estimation (nested loop 69x to 12x), = but the same ineffective plan is issued, without lexeme_idx:https://explain= .dalibo.com/plan/B7d#plan (has query with stats) On Sunday, August 8, 2021, 3:35:31 AM GMT+3, Justin Pryzby wrote: =20 =20 On Sat, Aug 07, 2021 at 07:35:25PM +0000, Alex wrote: > Table "product" has a GIN index on "lexeme" column (tsvector) that is not= used. >=20 > Query that doesn't use lexeme idx:=C2=A0=C2=A0https://explain.dalibo.com/= plan/BlB#plan, ~8s, ~60.000 blocks needed >=20 > Query forced to use lexeme idx: https://explain.dalibo.com/plan/i52, ~800= ms (10x less), ~15.000 blocks needed (x4 less) Could you show the table stats for product.id ?=C2=A0 In particular its "correlation". I guess the correlation is ~1, and the 10,659 index scans on product.id are considered to be cheaper than scannning the lexeme index - since there are = no correlation stats for tsvector. How large is shared_buffers ? Does the query plan improve if you increase work_mem ? Maybe you could encourage scanning in order of product_property.product. You could CLUSTER product_property_default on an index on "product" and the= n ANALYZE.=C2=A0 Or you could write the query with a temp table: CREATE TEMP TABLE product_ids AS SELECT product FROM product_property WHERE "meaning" =3D 'B' AND "first" =3D 1.7179869184E10 GROUP BY 1 -- or DISTINCT, because the table is only used for EXISTS ORDER BY 1; -- to scan product in order of id ANALYZE product_ids; The index scans on product.id should be faster when you use EXISTS(SELECT 1 FROM product_ids ...), even though it didn't use the lexeme= index. Maybe it would help to create stats on "first" and "meaning"; the rowcount = is underestimated by 3x, which means it did several times more index scans int= o "product" than planned. | Bitmap Heap Scan on product_property_default product_property_default (co= st=3D2,748.6..8,823.4 rows=3D6,318 width=3D4) (actual time=3D43.945..211.62= 1 rows=3D21,061 loops=3D1)=20 CREATE STATISTICS first_meaning ON first,meaning FROM product_property; ANALYZE product_property; > Table metdata: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 relname=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | relpages | reltuples | relallvisi= ble | relkind | relnatts | relhassubclass | reloptions | pg_table_size > --------------------------+----------+-----------+---------------+-------= --+----------+----------------+------------+--------------- > =C2=A0product_property_default |=C2=A0=C2=A0=C2=A0=C2=A0 8992 |=C2=A0=C2= =A0=C2=A0 622969 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 89= 92 | r=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 16 | f=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 73719808 > =C2=A0product=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 49686 |=C2= =A0=C2=A0=C2=A0 413840 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 49= 686 | r=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 14 | f=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 493314048 > > Table stats: > =C2=A0=C2=A0 frac_mcv=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 tablename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | at= tname | inherited | null_frac | n_distinct=C2=A0 | n_mcv | n_hist | correla= tion > ---------------+--------------------------+---------+-----------+--------= ---+-------------+-------+--------+------------- > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | product=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | lexeme=C2=A0 | f=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -1 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | > =C2=A0=C2=A0=C2=A0 0.99773335 | product_property_default | meaning | f=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 63 |=C2=A0=C2=A0=C2=A0 39 |=C2=A0=C2=A0=C2=A0=C2=A0 24 |=C2=A0 0.194= 44875 > =C2=A0=C2=A0=C2=A0=C2=A0 0.6416333 | product_property_default | first=C2= =A0=C2=A0 | f=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 2193 |=C2=A0=C2=A0 100 |=C2=A0=C2=A0=C2=A0 101 | -0.09763639 > =C2=A00.00023333334 | product_property_default | product | f=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0 | -0.15221785 |=C2=A0=C2=A0=C2=A0=C2=A0 1 |=C2=A0=C2=A0=C2= =A0 101 |=C2=A0 0.08643274 >=20 >=20 > Using windows docker with wsl2.Both cases are run with cold cache.All dat= abase memory is limited to 1GB by using .wslconfig file with memory=3D1GB, = also the docker container is limited to 1GB.=20 > My requirement is to optimize disk access with this limited memory =20 ------=_Part_740501_1260519995.1628415820925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Could you show th= e table stats for product.id ?  In particular its
"correlation".

 frac_mcv | tablename | attname | inherited | null_frac | n_dis= tinct | n_mcv | n_hist | correlation
----------+-----------+---------+--= ---------+-----------+------------+-------+--------+-------------
 =          | product   | id=       | f       = ;  |         0 |  &n= bsp;      -1 |      = |    101 |   0.3857521

> How large is shared_buffers ?
256MB

> Do= es the query plan improve if you increase work_mem ?
No, same plan.

> Maybe you could encourage scanning in order= of product_property.product...
Clustering "product_property_default" on "product_property_default_product_idx" followed by analyze, does not = change the plan.

> Or you could write the query = with a temp table:
Creating the temp table "product_= ids" changes the plan to use lexeme_idx: https://explain.dalibo.com= /plan/19h
B= ut I prefer not to use an extra step for my query.

> Maybe it would h= elp to create stats on "first" and "meaning"...
I've played around with statistics= , and increasing column stats with the extended statistics improve the plan= ner estimation (nested loop 69x to 12x), but the same ineffective plan is i= ssued, without lexeme_idx:


=20
=20
On Sunday, August 8, 2021, 3:35:31 AM GMT+3, Justin Pry= zby <pryzby@telsasoft.com> wrote:


On Sat, Aug 07, 2021 at 07:35:25PM +0000, Alex wrote:<= br clear=3D"none">> Table "product" has a GIN index on "lexeme" column (= tsvector) that is not used.
>
> = Query that doesn't use lexeme idx:  https://explain.dalibo.com/plan/BlB#plan, ~8s, ~60.000 blocks needed>
> Query forced to use lexeme id= x: https://explain.dalibo.com/plan/i52, ~800ms= (10x less), ~15.000 blocks needed (x4 less)

Could you show the table stats for product.id ?  In particular = its
"correlation".

I= guess the correlation is ~1, and the 10,659 index scans on product.id are<= br clear=3D"none">considered to be cheaper than scannning the lexeme index = - since there are no
correlation stats for tsvector.

How large is shared_buffers ?

Does the query plan improve if you increase work_m= em ?

Maybe you could encourage scannin= g in order of product_property.product.
You could CLUSTER= product_property_default on an index on "product" and then
ANALYZE.  Or you could write the query with a temp table:

CREATE TEMP TABLE product_ids AS
SELECT product
FROM product_property
WHERE "meaning" =3D 'B' AND "first" =3D 1.7179869184E10
GROUP BY 1 -- or DISTINCT, because the table is only used for EXISTS
ORDER BY 1; -- to scan product in order of id
ANALYZE product_ids;

The index scan= s on product.id should be faster when you use
EXISTS(SELE= CT 1 FROM product_ids ...), even though it didn't use the lexeme index.

Maybe it would help to create stats on "f= irst" and "meaning"; the rowcount is
underestimated by 3x= , which means it did several times more index scans into
= "product" than planned.
| Bitmap Heap Scan on product_pro= perty_default product_property_default (cost=3D2,748.6..8,823.4 rows=3D6,31= 8 width=3D4) (actual time=3D43.945..211.621 rows=3D21,061 loops=3D1)

CREATE STATISTICS first_meaning ON first,me= aning FROM product_property;
ANALYZE product_property;

> Table metdata:
> &nb= sp;        relname   &nbs= p;      | relpages | reltuples | relallvisible | r= elkind | relnatts | relhassubclass | reloptions | pg_table_size
> --------------------------+----------+-----------+-------------= --+---------+----------+----------------+------------+---------------
>  product_property_default |     = 8992 |    622969 |       =    8992 | r       |  &nbs= p;    16 | f        =       |       &= nbsp;    |      73719808
>  product        = ;          |   = 49686 |    413840 |      &nbs= p;  49686 | r       |   &= nbsp;   14 | f        &nb= sp;     |       &nbs= p;    |     493314048
= >
> Table stats:
>   = ; frac_mcv    |        ta= blename         | attname | inherit= ed | null_frac | n_distinct  | n_mcv | n_hist | correlation
> ---------------+--------------------------+---------+-------= ----+-----------+-------------+-------+--------+-------------
>            = ;    | product       &nbs= p;          | lexeme  | f=          |    &= nbsp;    0 |        =   -1 |       |    &n= bsp;   |
>     0.99773335 | p= roduct_property_default | meaning | f      &n= bsp;  |         0 |  = ;        63 |    39 |&nbs= p;    24 |  0.19444875
>  &nb= sp;   0.6416333 | product_property_default | first   | = f         |    =      0 |        2193= |   100 |    101 | -0.09763639
= >  0.00023333334 | product_property_default | product | f &nbs= p;       |      = ;   0 | -0.15221785 |     1 |  &nbs= p; 101 |  0.08643274
>
> > Using windows docker with wsl2.Both cases are run wit= h cold cache.All database memory is limited to 1GB by using .wslconfig file= with memory=3D1GB, also the docker container is limited to 1GB.
> My requirement is to optimize disk access with this limited = memory
------=_Part_740501_1260519995.1628415820925--