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)
For indexes the SSDs are at least 4X faster but you won't get that to happen
unless you fix the planner tunable for the random page fetch cost first. Super
important change for SSDs.
Matthew Hall
> On Oct 8, 2019, at 5:12 PM, Rick Otten wrote:
>
>
>> On Tue, Oct 8, 2019 at 7:37 PM Arya F w
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.
>
> Right now the database is running on a traditional HDD. SSDs have a much
> faster seek time than traditional HDDs.
>
> Would switchi
På onsdag 09. oktober 2019 kl. 01:37:06, skrev Arya F mailto:arya6...@gmail.com>>: As my table has gotten bigger, it takes longer to
get a single row back when querying a row by its btree index. Right now the
database is running on a traditional HDD. SSDs have a much faster seek time
than tradit
As my table has gotten bigger, it takes longer to get a single row back
when querying a row by its btree index.
Right now the database is running on a traditional HDD. SSDs have a much
faster seek time than traditional HDDs.
Would switching to an SSD improve "Index Only Scan" time greatly? by at
On Tue, Oct 8, 2019 at 12:44 PM Merlin Moncure wrote:
> On Sun, Apr 14, 2019 at 3:51 PM Gunther wrote:
> >
> > For weeks now, I am banging my head at an "out of memory" situation. There
> > is only one query I am running on an 8 GB system, whatever I try, I get
> > knocked out on this out of me
On Sun, Apr 14, 2019 at 3:51 PM Gunther wrote:
>
> For weeks now, I am banging my head at an "out of memory" situation. There is
> only one query I am running on an 8 GB system, whatever I try, I get knocked
> out on this out of memory. It is extremely impenetrable to understand and fix
> this
