Optimizing Postgresql ILIKE while query

Hi Team, Greetings for the day!! Platform: PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit Issue: We have the base table which contains 22M records and we created a view on top of it while querying the view with ILIKE clause it took

Re: BUG: Incorrect working with POSIX locale if database in UTF-8 encoding

I think correct behavior will be get the whole locale from postgresql.conf (like the backend processes do) or from environment. It’s a question, may be, from what place do take locale, but obviously from only one. But do not take LC_TYPE from the one place (postgresql.conf), while LC_MESSAGES

RE: Help with list partitioning on expression

Thank you! Thank you! Thank you! I would not have figured it out, but solution is so simple. Sent from Mail for Windows 10 From: David Rowley Sent: Sunday, October 21, 2018 6:50:47 PM To: Dinko Papak Cc:

Re: Help with list partitioning on expression

On 19 October 2018 at 02:49, Dinko Papak wrote: > I have created table partitioned by list on expression using timestamp > column, so for each timestamp value function returns int and each partition > table is for single value (range of timestamp for which function result is > the same). This

Re: found xmin x from before relfrozenxid y

Hi, On 2018-10-21 10:24:16 -0400, Tom Lane wrote: > =?UTF-8?Q?Johannes_Gra=c3=abn?= writes: > > after upgrading to version 11, I see the error pattern "found xmin x > > from before relfrozenxid y" in different databases on different hosts. > > From

Re: archive items not in correct section order

On 28/08/2018 21:51, Tom Lane wrote: Hm, could I trouble you for a self-contained test case? I tried to flesh it out as attached, but I'm not seeing any error with this. So there must be some other moving part ... regards, tom lane Tom, the materialized view in

Re: no queryId in post_parse_analyze hook when row is locked

Problem in pgsentinel has been identified, and should be fixed soon. it has nothing to do with post_parse_analyze hook. Sorry for the noise. Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html

Re: [proposal] pg_stat_statements: extension timing instrumentation

An other way is to use "waits" reporting ... something like : pgss_store (...) pgstat_report_wait_start(PG_WAIT_EXTENSION); ... pgstat_report_wait_end(); gives waits of type "Extension", name "Extension" when spending time in this part of pgss. This can help those

Re: found xmin x from before relfrozenxid y

Thanks for your answer. On 21/10/2018 16.24, Tom Lane wrote: > In the meantime, the only answer I can think of offhand is to manually > do VACUUM FREEZE on each of your MVs, and then refresh anything that > shows up with an error. Since I have so many of them, I decided to go for a

Re: found xmin x from before relfrozenxid y

=?UTF-8?Q?Johannes_Gra=c3=abn?= writes: > after upgrading to version 11, I see the error pattern "found xmin x > from before relfrozenxid y" in different databases on different hosts. > From https://www.postgresql.org/docs/10/static/release-10-3.html, I > learned that this was an error caused by

Re: Postgres 10, slave not catching up with master

On 10/21/18 2:06 AM, Boris Sagadin wrote: Hello, I have a database running on i3.8xlarge (256GB RAM, 32 CPU cores, 4x 1.9TB NVMe drive) AWS instance with about 5TB of disk space occupied, ext4, Ubuntu 16.04. Multi-tenant DB with about 4 tables, insert heavy. I started a new slave with

Postgres 10, slave not catching up with master

Hello, I have a database running on i3.8xlarge (256GB RAM, 32 CPU cores, 4x 1.9TB NVMe drive) AWS instance with about 5TB of disk space occupied, ext4, Ubuntu 16.04. Multi-tenant DB with about 4 tables, insert heavy. I started a new slave with identical HW specs, SR. DB started syncing from

found xmin x from before relfrozenxid y

Hi, after upgrading to version 11, I see the error pattern "found xmin x from before relfrozenxid y" in different databases on different hosts. From https://www.postgresql.org/docs/10/static/release-10-3.html, I learned that this was an error caused by pg_upgrade, which apparently had been fixed