Re: [GENERAL] Understanding "seq scans"

Merlin Moncure writes: > On Tue, Oct 13, 2015 at 11:54 AM, Alvaro Herrera > wrote: >> Be very careful with a % at the left. The index is not going to work at >> all there. It is not the same as looking for stuff without a % at the >> left. > > Note, you can optimize LIKE '%foo%' with pg_trgm/

Re: [GENERAL] Understanding "seq scans"

On Tue, Oct 13, 2015 at 11:54 AM, Alvaro Herrera wrote: > Lele Gaifax wrote: >> Alvaro Herrera writes: >> >> > So 10% of your rows in the master_l10n table start with "quattro"? >> > That's pretty odd, isn't it? How did you manufacture these data? >> >> Well, not a real scenario for sure, but de

Re: [GENERAL] Understanding "seq scans"

Alvaro Herrera writes: > I imagined it would be something like that. It's not the most useful > set of test data, precisely because it doesn't accurately reflect what > you're going to have in practice. I suggest you enter some actual text, > even if it's just text from Don Camillo or whatever.

Re: [GENERAL] Understanding "seq scans"

Lele Gaifax wrote: > Alvaro Herrera writes: > > > So 10% of your rows in the master_l10n table start with "quattro"? > > That's pretty odd, isn't it? How did you manufacture these data? > > Well, not a real scenario for sure, but definitely not odd: I just needed an > "extremely" big dataset to

Re: [GENERAL] Understanding "seq scans"

Merlin Moncure writes: > Your data and indexes are organized such that an index is only marginally > helpful, or so the planner thinks. Yes, just wanted to get rid of that suspicious "seq scan", that was effectively caused by a bad index, as Alvaro pointed out. Thank you, ciao, lele. -- nickna

Re: [GENERAL] Understanding "seq scans"

Alvaro Herrera writes: > So 10% of your rows in the master_l10n table start with "quattro"? > That's pretty odd, isn't it? How did you manufacture these data? Well, not a real scenario for sure, but definitely not odd: I just needed an "extremely" big dataset to test out several different strat

Re: [GENERAL] Understanding "seq scans"

On Monday, October 12, 2015, Lele Gaifax wrote: > Adrian Klaver > writes: > > > Off hand I would say it is because of this --> count(m.num). Try > count(l.num) instead and see > > what happens. As your queries above show they are the same number. > > No, that's another thing I already tried tweak

Re: [GENERAL] Understanding "seq scans"

Lele Gaifax wrote: > Hi all, > > I'm doing some experiments to find the better layout for reimplementing > an existing db (MySQL cough!) with PostgreSQL 9.4+. > > I noticed a strange plan coming out from a simple query joining two tables, > both containing 10Mrecs (and both ANALYZEd): >

Re: [GENERAL] Understanding "seq scans"

Adrian Klaver writes: > Off hand I would say it is because of this --> count(m.num). Try count(l.num) > instead and see > what happens. As your queries above show they are the same number. No, that's another thing I already tried tweaking and should have mentioned. Neither count(*) nor count(l.

Re: [GENERAL] Understanding "seq scans"

On 10/12/2015 12:06 PM, Lele Gaifax wrote: Hi all, I'm doing some experiments to find the better layout for reimplementing an existing db (MySQL cough!) with PostgreSQL 9.4+. I noticed a strange plan coming out from a simple query joining two tables, both containing 10Mrecs (and both ANALYZEd):

Re: [GENERAL] Understanding "seq scans"

On Monday, October 12, 2015 2:52 PM, Lele Gaifax wrote: > I'm doing some experiments to find the better layout for > reimplementing an existing db (MySQL cough!) with PostgreSQL > 9.4+. > > I noticed a strange plan coming out from a simple query joining > two tables, both containing 10Mrecs (and

[GENERAL] Understanding "seq scans"

Hi all, I'm doing some experiments to find the better layout for reimplementing an existing db (MySQL cough!) with PostgreSQL 9.4+. I noticed a strange plan coming out from a simple query joining two tables, both containing 10Mrecs (and both ANALYZEd): l10ntest=# \d master;