Re: [GENERAL] SELECT slow immediately after many update or delete+insert, except using WHERE .. IN

2016-12-10 15:41 GMT+01:00 Adrian Klaver : > On 12/10/2016 04:21 AM, Tom DalPozzo wrote: > >> Hi, >> my release is 9.5.4. >> a took a look over it. I guessed that counting could be slow because it >> needs to read everything and also that it can take advantage from an

Re: [GENERAL] SELECT slow immediately after many update or delete+insert, except using WHERE .. IN

On 12/10/2016 04:21 AM, Tom DalPozzo wrote: Hi, my release is 9.5.4. a took a look over it. I guessed that counting could be slow because it needs to read everything and also that it can take advantage from an index. But I don't understand why the delay is after the updates for a Best guess,

Re: [GENERAL] SELECT slow immediately after many update or delete+insert, except using WHERE .. IN

Hi, my release is 9.5.4. a took a look over it. I guessed that counting could be slow because it needs to read everything and also that it can take advantage from an index. But I don't understand why the delay is after the updates for a certain time and why WHERE..IN is much faster (ok, it's an

Re: [GENERAL] SELECT slow immediately after many update or delete+insert, except using WHERE .. IN

On 12/09/2016 08:03 AM, Tom DalPozzo wrote: > Hi, > I did two tests: > TEST 1 > 1 I created a table ("Table") with two fields, one ("Id") is a bigint > and the other ("Data") is a bytea. Also created an index on Id. > 2 Populated the table with 1 rows, in which the bigint is > incremental and

[GENERAL] SELECT slow immediately after many update or delete+insert, except using WHERE .. IN

Hi, I did two tests: TEST 1 1 I created a table ("Table") with two fields, one ("Id") is a bigint and the other ("Data") is a bytea. Also created an index on Id. 2 Populated the table with 1 rows, in which the bigint is incremental and bytea is 1000 bytes long. 3 Executed SELECT COUNT(*) FROM