Alexander Stoddard writes:
> Thank you for this. I can get different plans by changing the different
> parameters, but if the output of EXPLAIN VERBOSE tells me geqo planning
> specifically is being used I'm not seeing it. Is there a way to see in the
> explain plan if geqo was used?
It's not re
On Tue, Jan 19, 2021 at 2:47 PM Michael Lewis wrote:
> On Fri, Jan 15, 2021 at 3:27 PM Alexander Stoddard <
> alexander.stodd...@gmail.com> wrote:
>
>> I am doing nothing to specify the optimizer. Do I have configurable
>> options in that regard? I was unaware of them.
>>
>
> Read up on join_coll
On Fri, Jan 15, 2021 at 3:27 PM Alexander Stoddard <
alexander.stodd...@gmail.com> wrote:
> The queries are complex, multiple joins to 10 plus tables, although most
> are to tiny enum type lookup tables. I believe it is the join between the
> two large tables that I have described that causes the
On Fri, Jan 15, 2021 at 12:27 PM Michael Lewis wrote:
> On Fri, Jan 15, 2021 at 10:22 AM Alexander Stoddard <
> alexander.stodd...@gmail.com> wrote:
>
>> The 'fast plans' use parallel seq scans. The 'slow plans' is using index
>> scans. It appears a good query plan correctly predicts it should be
On 1/15/21 11:54 AM, Adrian Klaver wrote:
On 1/15/21 10:49 AM, Alexander Stoddard wrote:
Please reply to list also.
Ccing list.
So to be clear, the process imports the data, then you run a query
and
it completes in x time, you then ANALYZE the same data and it runs
in y
time. I
On 1/15/21 10:49 AM, Alexander Stoddard wrote:
Please reply to list also.
Ccing list.
So to be clear, the process imports the data, then you run a query and
it completes in x time, you then ANALYZE the same data and it runs in y
time. Is that correct?
The process imports data, ANA
On Fri, Jan 15, 2021 at 9:10 AM Thomas Kellerer wrote:
> Maybe there are many "idle in transaction" sessions that prevent
> autovacuum from properly
> analyzing those tables. Or maybe for some unknown reason autovacuum was
> turned off.
> Or maybe they receive a lot of bulk loads which would requ
On Fri, Jan 15, 2021 at 10:22 AM Alexander Stoddard <
alexander.stodd...@gmail.com> wrote:
> The 'fast plans' use parallel seq scans. The 'slow plans' is using index
> scans. It appears a good query plan correctly predicts it should be bulk
> processing the tables but bad ones get fooled into tras
On 1/15/21 9:21 AM, Alexander Stoddard wrote:
Unfortunately I'm not free to share the specific schema or the query
plans. They derive from an upstream vendor that is 'protective' of their
data model. To get to a proper example I'll need to recreate the
behavior with generic data in a generified
Unfortunately I'm not free to share the specific schema or the query plans.
They derive from an upstream vendor that is 'protective' of their data
model. To get to a proper example I'll need to recreate the behavior with
generic data in a generified schema.
I apologize for being frustratingly vagu
On Fri, Jan 15, 2021 at 9:10 AM Thomas Kellerer wrote:
> Atul Kumar schrieb am 15.01.2021 um 16:29:
> > As per Ron, you are not supposed to ask your questions here.
> >
> > As According to him, we should keep on doing research on internet
> > rather than asking for support directly even you have
Atul Kumar schrieb am 15.01.2021 um 16:29:
As per Ron, you are not supposed to ask your questions here.
As According to him, we should keep on doing research on internet
rather than asking for support directly even you have done enough
research and until unless “Ron” won’t be satisfied you have
On Fri, Jan 15, 2021 at 8:44 AM Atul Kumar wrote:
> Hi Ron,
>
> I have a simple mindset that If I don’t know about something about
> anyone’s query I don’t respond.
>
> Please start learning to not to interrupt or raising useless questions/
> phrases on someone’s query bcz it makes you judgementa
Hi Ron,
I have a simple mindset that If I don’t know about something about anyone’s
query I don’t respond.
Please start learning to not to interrupt or raising useless questions/
phrases on someone’s query bcz it makes you judgemental.
So please take an advice to not to interrupt if you can’t he
On Fri, Jan 15, 2021 at 9:29 AM Atul Kumar wrote:
>
> Hi Alexander,
>
> As per Ron, you are not supposed to ask your questions here.
>
> As According to him, we should keep on doing research on internet rather than
> asking for support directly even you have done enough research and until
> unle
Hi Alexander,
As per Ron, you are not supposed to ask your questions here.
As According to him, we should keep on doing research on internet rather
than asking for support directly even you have done enough research and
until unless “Ron” won’t be satisfied you have to do keep on researching.
On 1/15/21 9:19 AM, Alexander Stoddard wrote:
I am having ongoing trouble with a pair of tables, the design of which is
beyond my control.
There is a 'primary' table with hundreds of millions of rows. There is
then a 'subclass' table ~ 10% of the primary which has additional fields.
The table
I am having ongoing trouble with a pair of tables, the design of which is
beyond my control.
There is a 'primary' table with hundreds of millions of rows. There is then
a 'subclass' table ~ 10% of the primary which has additional fields. The
tables logically share a primary key field (although tha
18 matches
Mail list logo
