Thanks Tom.
Since you mentioned the planner not knowing about the correlation between the
columns, I’m curious, why doesn’t making a multivariate statistic make a
difference?
CREATE STATISTICS col_a_col_b_stats (dependencies) ON col_a, col_b FROM
test_table;
ANALYZE test_table;
And the result
Thanks so much for your help, Tom.
Sorry, I didn’t quite understand the answer — I have a few follow-up questions.
Sorry, I'm new to Postgres so I am a bit ignorant here and would appreciate
any tips on the query planner you could give.
1) Why is the query currently picking the poorly perform
On Thu, 3 Apr 2025 at 18:07, Tom Lane wrote:
> A simple-minded approach could be to just be pessimistic, and
> increase our estimate of how many rows would need to be scanned as a
> consequence of noticing that the columns have significant correlation.
> The shape of that penalty function would be
David Rowley writes:
> On Thu, 3 Apr 2025 at 16:24, Manikandan Swaminathan
> wrote:
>> why doesn’t making a multivariate statistic make a difference?
> Extended statistics won't help you here. "dependencies" just estimates
> functional dependencies between the columns mentioned in the ON
> claus
On Thu, 3 Apr 2025 at 16:24, Manikandan Swaminathan
wrote:
> Since you mentioned the planner not knowing about the correlation between the
> columns, I’m curious, why doesn’t making a multivariate statistic make a
> difference?
>
>
> CREATE STATISTICS col_a_col_b_stats (dependencies) ON col_a, c
Manikandan Swaminathan writes:
> 1) Why is the query currently picking the poorly performing index?
Because the planner thinks that one will be cheaper, as you can see by
comparing the cost estimates in EXPLAIN. It's wrong, but this is a
hard problem to estimate well. Especially when the behavi
Hello,
I'm running on the docker postgres:17.0 image and trying to test out the
behavior of adding a new index to a table. Specifically, I wanted to verify
that my new index is actually used by looking at the output of "EXPLAIN
ANALYZE". However, I found that my index is often not being used and w
Manikandan Swaminathan writes:
> 4. When running the following query, I would expect the index "idx_col_b_a"
> to be used: select min(col_b) from test_table where col_a > 4996.
> I have a range-based filter on col_a, and am aggregating the result with
> min(col_b). Both columns are covered by "id
On 4/27/23 17:58, Michael Xu wrote:
Please reply to list also.
Ccing list.
1) Are you sure whatever client you are using is not doing
"ads.MyTableName"?
Confirm, it is not ads.MyTableName.
1) What client(and it's version) are you using?
2) What I asked was whether the schema and table nam
> On Apr 27, 2023, at 12:40 PM, Michael Xu wrote:
>
>
> Hi,
>
> By default, pgsql accepts double quotes around schema's name in a query, e.g.
> select * from "ads"."MyTableName". In our env, it throws 42P01:relation
> "ads.MyTableName" does not exist. It is okay if no double quote around s
On 4/27/23 12:40, Michael Xu wrote:
Hi,
By default, pgsql accepts double quotes around schema's name in a query,
e.g. select * from "ads"."MyTableName". In our env, it throws
42P01:relation "ads.MyTableName" does not exist. It is okay if no double
quote around schema name, select * from ads."
> On Apr 27, 2023, at 12:40, Michael Xu wrote:
> In our env, it throws 42P01:relation "ads.MyTableName" does not exist.
The function of double quotes in SQL is to allow you do include characters that
would otherwise not be legal in an identifier (as well as making the identifier
case-sensiti
Michael Xu writes:
> By default, pgsql accepts double quotes around schema's name in a query,
> e.g. select * from "ads"."MyTableName". In our env, it throws
> 42P01:relation "ads.MyTableName" does not exist.
Works for me:
regression=# create schema ads;
CREATE SCHEMA
regression=# create table "
Hi,
By default, pgsql accepts double quotes around schema's name in a query,
e.g. select * from "ads"."MyTableName". In our env, it throws
42P01:relation "ads.MyTableName" does not exist. It is okay if no double
quote around schema name, select * from ads."MyTableName".
Is there settings in pssql
On Fri, Mar 11, 2022 at 10:02:39AM +, Ian Dauncey wrote:
> Can anyone assist in shedding some light here.
> We getting this query popping up in our postgresql log file at the same time
> as the connections to the databases starts increasing.
> Not sure what is initiating this query, but we get
Hi All
Can anyone assist in shedding some light here.
We getting this query popping up in our postgresql log file at the same time as
the connections to the databases starts increasing.
Not sure what is initiating this query, but we get around a hundred per second
until we restart our applicati
16 matches
Mail list logo
