On Wed, May 21, 2025 at 11:09 AM Adrian Klaver
wrote:
> On 5/20/25 11:06, Tessa Niebel wrote:
> > I really need to get PostgresSQL working because I’m a college student
> > using this for class. I have never worked with PostgresSQL before please
> > let me know what I need to do as soon as possib
On 5/20/25 11:06, Tessa Niebel wrote:
I really need to get PostgresSQL working because I’m a college student
using this for class. I have never worked with PostgresSQL before please
let me know what I need to do as soon as possible.
You will have to explain what is not working as the connectio
On Tue, May 20, 2025 at 02:06:33PM -0400, Tessa Niebel wrote:
> I really need to get PostgresSQL working because I’m a college student
> using this for class. I have never worked with PostgresSQL before please
> let me know what I need to do as soon as possible.
1. Doing photo of screen is ... wel
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
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 "
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
16 matches
Mail list logo
