Hi,
I have had a perf (++) pb with a join plan cf the pb with join plan thread.
I did simplify the thing up to when its a simple join between a 15M lines
table and a 30k lines table.
if I put in the on part something like table1.a=table2.b, Postgres does the
job in around 1 seconde.
if in the on
OK, I see, I'm so sorry for my action.
I will ask in cpplang slack community in the future.
And really thanks for your advice.
Your,
Wen Yi
-- Original --
From:
On 6/25/23 10:01, Marc Millas wrote:
Hi,
I have had a perf (++) pb with a join plan cf the pb with join plan thread.
I did simplify the thing up to when its a simple join between a 15M lines
table and a 30k lines table.
if I put in the on part something like table1.a=table2.b, Postgres does
t
On Tue, Jun 13, 2023 at 3:28 PM Patrick O'Toole
wrote:
> run the query twice first, then...
Is that a realistic way to run the test? Often forcing all the data needed
for the query into memory is going to make things less realistic, not more
realistic. Assuming the system has more stuff to do
On Mon, 26 Jun 2023 at 03:02, Marc Millas wrote:
> When I ask this list, David Rowley suggest to rewrite the SQL, replacing the
> OR by a union.
>
> Fine, this do work, even if a bit complex as the original SQL was a set of
> intricate joins.
>
>
> So, either this behaviour ( postgres unable to
On Sun, Jun 25, 2023 at 9:35 PM David Rowley wrote:
> On Mon, 26 Jun 2023 at 03:02, Marc Millas wrote:
> > When I ask this list, David Rowley suggest to rewrite the SQL, replacing
> the OR by a union.
> >
> > Fine, this do work, even if a bit complex as the original SQL was a set
> of intricate
On Wed, 14 Jun 2023 at 07:28, Patrick O'Toole wrote:
> Maybe we are barking up the wrong tree with the previous questions. Are there
> other configuration parameters we should consider first to improve
> performance in situations like the one illustrated?
random_page_cost and effective_cache_si
David Rowley writes:
> The problem is that out of the 3 methods PostgreSQL uses to join
> tables, only 1 of them supports join conditions with an OR clause.
> Merge Join cannot do this because results can only be ordered one way
> at a time. Hash Join technically could do this, but it would requi
On Sun, Jun 25, 2023 at 11:48 PM Tom Lane wrote:
> David Rowley writes:
> > The problem is that out of the 3 methods PostgreSQL uses to join
> > tables, only 1 of them supports join conditions with an OR clause.
> > Merge Join cannot do this because results can only be ordered one way
> > at a t
Sounds like the problem you are having is, the server is running out of
temporary resources for the operation that users are trying to do. So
according to Tom, on the postgres side, the operation cannot be optimized
further.
I think you have few choices here,
- See if increasing the resources of
On Friday, June 23rd, 2023 at 2:52 PM, Laurenz Albe
wrote:
>
>
> On Fri, 2023-06-23 at 12:08 +, Nicolas Seinlet wrote:
>
> > we faced an issue with a select query on a relatively large table on our
> > database.
> > The query involves one single table. The table has more than 10 mill
Hello,I use multi-schemas in one database in Postgres,such as
```
Postgres(instance)
MyDB
public
MySchema1
table1
table2
MySchema2
table1
table2
MySchema3
table1
table2
```
And It's open to my users,my users will run queries,
such as
User1:
```
set searc
12 matches
Mail list logo
