On Thu, 28 Apr 2016 16:38:53 +0200
Alban Hertroys wrote:
Hi Alban
First off ... thanks you for your time on this so far and giving me the
educational smacks on the head :) I appreciate this a lot.
> You're doing ~9 times as many index lookups. A slowdown of 6x of this
> part of the query seem
On Wed, 27 Apr 2016 13:48:06 +0200
Alban Hertroys wrote:
> In this case, you're using the values in adverse to filter relevant rid's for
> the FK join, so you might be better off with the inverse of above index:
> create index on report_adverses (adverse, rid);
> create index on repo
On Wed, 27 Apr 2016 13:48:06 +0200
Alban Hertroys wrote:
Hi Alban
Thanks for chiming in!
> Since you're not using age and gender in this (particular) query until the
> rows are combined into a result set already, it doesn't make a whole lot of
> sense to add them to the index. Moreover, since
On Wed, 27 Apr 2016 22:40:43 +1200
David Rowley wrote:
Hi David
> > ...
> > Planning time: 15.968 ms
> > Execution time: 4313.755 ms
> >
> > Both the (rid, adverse) and the (id, age, gender, created) indexes are now
> > used.
> >
>
> Seems the (rid, adverse) is not being used. report_adverse
On Wed, 27 Apr 2016 09:14:27 +0300
Victor Yegorov wrote:
Hi Victor
> > ...
>
> Can you post output of `EXPLAIN (analyze, buffers)`, please?
> It'd be good to check how many buffers are hit/read during Index Scans.
Happy to, here it is:
Sort (cost=107727.85..107728.71 rows=344 width=41) (act
On Wed, 27 Apr 2016 14:09:04 +1200
David Rowley wrote:
Hi David
Thanks for your time on this. I tried your proposals with the results below.
> > ...
> > Under 5 ms. The same goes for querying the "adverse" column in the
> > "report_adverses" table: under 20 ms.
>
> I'm not sure why you're com
On Wed, 27 Apr 2016 01:45:55 +
Sameer Kumar wrote:
Hi Sameer
Thanks for taking the time to look into this!
> > ...
> Quite clearly the nested loop joins are the most costly operations here.
Indeed.
> > ...
> I suppose. It might help if the filters are performed before the join. I am
> n
Hi all
I have asked this question in a somewhat different form on the DBA
Stackexchange site, but without much luck
(https://dba.stackexchange.com/questions/136423/postgresql-slow-join-on-three-large-tables).
So I apologize for possible double posting, but I hope this might get a better
respon
On Wed, 21 Oct 2015 13:40:38 + (UTC)
Kevin Grittner wrote:
> > Damn, I completely overlooked that one, and it indeed does seem
> > to come very close to what I need in this use case.
>
> I have to admit that the name of that dictionary type threw me off
> a bit at first.
Indeed :)
> > ...
On Tue, 20 Oct 2015 12:02:46 +0100
> Does the Thesaurus dictionary not do what you want?
>
> http://www.postgresql.org/docs/current/static/textsearch-dictionaries.html#TEXTSEARCH-THESAURUS
Damn, I completely overlooked that one, and it indeed does seem to come very
close to what I need in th
On Tue, 20 Oct 2015 21:57:59 +1100
rob stone wrote:
>
> Looking at this from an entirely different perspective, why are you not
> using ICD codes to identify patient events?
> It is a one to many relationship between patient and their events
> identified by the relevant ICD code and date.
> Given
Hi All
I have a question regarding PostgreSQL's full text capabilities and
(presumably) the synonym dictionary.
I'm currently implementing FTS on a medical themed setup which uses domain
specific jargon to denote a bunch of stuff. A specific request I wish to
implement here are the jargon syno
n "appendix" chapter which
mentions xsyn...or just update my posts.
Cheers,
Tim
> On Sat, May 3, 2014 at 2:26 AM, Tim van der Linden wrote:
> > Hi Oleg
> >
> > Haha, understood!
> >
> > Thanks for helping me on this one.
> >
> > Cheers
>
Hi all
Another question regarding full text, this time about ranking.
The ts_ranking() and ts_ranking_cd() accept a normalization integer/bit mask.
In the documentation the different integers are somewhat laid out and it is
said that some take into account the document length (1 and 2) while oth
Hi Oleg
Haha, understood!
Thanks for helping me on this one.
Cheers
Tim
On May 3, 2014 7:24:08 AM GMT+09:00, Oleg Bartunov wrote:
>Tim,
>
>you did answer yourself - don't use ispell :)
>
>On Sat, May 3, 2014 at 1:45 AM, Tim van der Linden
>wrote:
>> On Fri, 2 Ma
if I do not desire this behavior I
should maybe not use Ispell and simply use another dictionary :)
Thanks again.
Cheers,
Tim
> On Fri, May 2, 2014 at 11:54 AM, Tim van der Linden wrote:
> > Good morning/afternoon all
> >
> > I am currently writing a few articles about Postgre
Good morning/afternoon all
I am currently writing a few articles about PostgreSQL's full text capabilities
and have a question about the Ispell dictionary which I cannot seem to find an
answer to. It is probably a very simple issue, so forgive my ignorance.
In one article I am explaining about
17 matches
Mail list logo
