Ogden Brash writes:
> I have a question about the files in .../data/postgresql/11/main/
> base, specifically in relation to very large tables and how they are
> written.
>
> I have been attempting to restore a relatively large database with
> pg_restore and it has been running for more than a
On Thu, 10 Oct 2019 at 01:07, Behrang Saeedzadeh wrote:
>
> This is a follow up to
> https://www.postgresql.org/message-id/flat/CAERAJ%2B-1buiJ%2B_JWEo0a9Ao-CVMWpgp%3DEnFx1dJtnB3WmMi2zQ%40mail.gmail.com
>
> The query (generated by Hibernate) got a bit more complex and performance
> degraded
On Tue, Oct 8, 2019 at 7:37 PM Arya F wrote:
> As my table has gotten bigger, it takes longer to get a single row back
> when querying a row by its btree index.
>
>
Is this in a probabilistic sense, they take longer on average, or has every
single access gotten slower? If the increase in size
Are you prefixing this auto generated query with set join_collapse_limit =
30, or are you changing the default and reloading config? That is, can you
impact ONLY this query with these config changes? I wouldn't assume so, so
any hack/query hint like turning off hashjoins (which seem to be chosen
On Wed, Oct 9, 2019 at 4:33 AM Ogden Brash wrote:
> # lsof -p 6600 | wc -l;
> 840
>
> # lsof -p 6601 | wc -l;
> 906
>
> Is that normal? That there be so many open file pointers? ~900 open file
> pointers for each of the processes?
>
I don't think PostgreSQL makes any effort to conserve file
On Wed, 9 Oct 2019 at 19:21, Behrang Saeedzadeh wrote:
>
> Is there a way to display the planner algorithm used by a query, either in
> EXPLAIN or in a different way?
There's not really any simple way to know. If the number of relations
in the join search meets or exceeds geqo_threshold then
Michael Lewis writes:
>> When you join to a view, the view sticks together, as if they were all in
>> parentheses. But when you substitute the text of a view into another
>> query, then they are all on the same level and can be parsed differently.
>>
>> Consider the difference between "1+1 *
>
> When you join to a view, the view sticks together, as if they were all in
> parentheses. But when you substitute the text of a view into another
> query, then they are all on the same level and can be parsed differently.
>
> Consider the difference between "1+1 * 3", and "(1+1) * 3"
>
I
On Wed, Oct 9, 2019 at 10:56 AM Yavuz Selim Sertoğlu (ETIYA) <
yavuz.serto...@etiya.com> wrote:
> Thanks for the reply Tom,
>
> Sorry, I couldn't understand. I just copied inside of view and add
> conditions from query that runs with view.
> The comma parts are the same in two queries, one is
>
> Those are not equivalent queries. Read up on the syntax of FROM;
> particularly, that JOIN binds more tightly than comma.
>
I see this-
"A JOIN clause combines two FROM items, which for convenience we will refer
to as “tables”, though in reality they can be any type of FROM item. Use
Thanks for the reply Tom,
Sorry, I couldn't understand. I just copied inside of view and add conditions
from query that runs with view.
The comma parts are the same in two queries, one is inside of view the other is
in the query.
-Original Message-
From: Tom Lane
Sent: 09 October
=?iso-8859-9?Q?Yavuz_Selim_Serto=F0lu_=28ETIYA=29?=
writes:
> I have a problem with views. When I use view in my query it really slows
> down(1.7seconds)
> If I use inside of view and add conditions and joins to it, it is really
> fast(0.7 milliseconds).
> I have no distinct/group/partition by
Hi all,
I have a problem with views. When I use view in my query it really slows
down(1.7seconds)
If I use inside of view and add conditions and joins to it, it is really
fast(0.7 milliseconds).
I have no distinct/group/partition by in view so I have no idea why is this
happening.
I wrote
This is a follow up to
https://www.postgresql.org/message-id/flat/CAERAJ%2B-1buiJ%2B_JWEo0a9Ao-CVMWpgp%3DEnFx1dJtnB3WmMi2zQ%40mail.gmail.com
The query (generated by Hibernate) got a bit more complex and performance
degraded again. I have uploaded all the details here (with changed table
names,
> "Ogden" == Ogden Brash writes:
Ogden> I have a question about the files in
Ogden> .../data/postgresql/11/main/base, specifically in relation to
Ogden> very large tables and how they are written.
Ogden> I have been attempting to restore a relatively large database
Ogden> with
I have a question about the files in .../data/postgresql/11/main/base,
specifically in relation to very large tables and how they are written.
I have been attempting to restore a relatively large database with
pg_restore and it has been running for more than a week. (I also have
another thread
Is there a way to display the planner algorithm used by a query, either in
EXPLAIN or in a different way?
Regards,
Behrang (sent from my mobile)
17 matches
Mail list logo
