Greetings,
* Ron (ronljohnso...@gmail.com) wrote:
> On 12/05/2018 08:42 AM, Chris Withers wrote:
> >On 05/12/2018 14:38, Stephen Frost wrote:
> * Chris Withers (ch...@withers.org) wrote:
> >>>Interesting! In my head, for some reason, I'd always assumed a btree index
> >>>would break down a cha
On 12/05/2018 08:42 AM, Chris Withers wrote:
On 05/12/2018 14:38, Stephen Frost wrote:
Greetings,
* Chris Withers (ch...@withers.org) wrote:
On 30/11/2018 15:33, Stephen Frost wrote:
* Chris Withers (ch...@withers.org) wrote:
On 28/11/2018 22:49, Stephen Frost wrote:
For this, specifically,
On 05/12/2018 14:38, Stephen Frost wrote:
Greetings,
* Chris Withers (ch...@withers.org) wrote:
On 30/11/2018 15:33, Stephen Frost wrote:
* Chris Withers (ch...@withers.org) wrote:
On 28/11/2018 22:49, Stephen Frost wrote:
For this, specifically, it's because you end up with exactly what you
Greetings,
* Chris Withers (ch...@withers.org) wrote:
> On 30/11/2018 15:33, Stephen Frost wrote:
> >* Chris Withers (ch...@withers.org) wrote:
> >>On 28/11/2018 22:49, Stephen Frost wrote:
> >For this, specifically, it's because you end up with exactly what you
> >have: a large index with tons of
Greetings,
* Thomas Kellerer (spam_ea...@gmx.net) wrote:
> Stephen Frost schrieb am 30.11.2018 um 14:05:
> > PG doesn’t know, with complete certainty, that there’s only 3
> > values.
>
> Would the optimizer consult a check constraint ensuring that?
Not today, I don't believe (haven't looked at
Chris Withers schrieb am 05.12.2018 um 12:42:
> So, interestingly, this box has 250GB memory in it, and even though
> I've set effective_cache_size to 200GB, I only see 9G of memory being
> used. How can I persuade postgres to keep more in memory?
effective_cache_size is a hint to the optimizer on
Stephen Frost schrieb am 30.11.2018 um 14:05:
> PG doesn’t know, with complete certainty, that there’s only 3
> values.
Would the optimizer consult a check constraint ensuring that?
On 30/11/2018 22:10, Gavin Flower wrote:
I once optimised a very complex set queries that made extensive use of
indexes. However, with the knowledge I have today, I would have most
likely had fewer and smaller indexes. As I now realize, that some of my
indexes were probably counter producti
On 30/11/2018 15:33, Stephen Frost wrote:
Greetings,
* Chris Withers (ch...@withers.org) wrote:
On 28/11/2018 22:49, Stephen Frost wrote:
* Chris Withers (ch...@withers.org) wrote:
We have an app that deals with a lot of queries, and we've been slowly
seeing performance issues emerge. We take
On 01/12/2018 04:33, Stephen Frost wrote:
Greetings,
* Chris Withers (ch...@withers.org) wrote:
On 28/11/2018 22:49, Stephen Frost wrote:
* Chris Withers (ch...@withers.org) wrote:
We have an app that deals with a lot of queries, and we've been slowly
seeing performance issues emerge. We take
Greetings,
* Chris Withers (ch...@withers.org) wrote:
> On 28/11/2018 22:49, Stephen Frost wrote:
> >* Chris Withers (ch...@withers.org) wrote:
> >>We have an app that deals with a lot of queries, and we've been slowly
> >>seeing performance issues emerge. We take a lot of free form queries from
>
Greetings,
On Fri, Nov 30, 2018 at 08:00 Chris Withers wrote:
> On 30/11/2018 12:55, Stephen Frost wrote:
> > > I'd suggest you check out the wiki article written about this
> kind of
> > > question:
> > >
> > > https://wiki.postgresql.org/wiki/Slow_Query_Questions
> >
> >
>
On 30/11/2018 12:55, Stephen Frost wrote:
> I'd suggest you check out the wiki article written about this kind of
> question:
>
> https://wiki.postgresql.org/wiki/Slow_Query_Questions
Have you tried a partial index on state!=‘RSV’?
The solution I originally posted, that we
Greetings,
On Fri, Nov 30, 2018 at 07:52 Chris Withers wrote:
> On 28/11/2018 22:49, Stephen Frost wrote:
> > * Chris Withers (ch...@withers.org) wrote:
> >> We have an app that deals with a lot of queries, and we've been slowly
> >> seeing performance issues emerge. We take a lot of free form q
On 28/11/2018 22:49, Stephen Frost wrote:
* Chris Withers (ch...@withers.org) wrote:
We have an app that deals with a lot of queries, and we've been slowly
seeing performance issues emerge. We take a lot of free form queries from
users and stumbled upon a very surprising optimisation.
So, we ha
Greetings,
* Chris Withers (ch...@withers.org) wrote:
> We have an app that deals with a lot of queries, and we've been slowly
> seeing performance issues emerge. We take a lot of free form queries from
> users and stumbled upon a very surprising optimisation.
>
> So, we have a 'state' column whi
On 29/11/2018 11:26, Chris Withers wrote:
Hi All,
We have an app that deals with a lot of queries, and we've been slowly
seeing performance issues emerge. We take a lot of free form queries
from users and stumbled upon a very surprising optimisation.
So, we have a 'state' column which is a 3
On 11/28/18 2:26 PM, Chris Withers wrote:
Hi All,
We have an app that deals with a lot of queries, and we've been slowly
seeing performance issues emerge. We take a lot of free form queries
from users and stumbled upon a very surprising optimisation.
So, we have a 'state' column which is a 3
18 matches
Mail list logo
