Re: Huge input lookup exception when trying to create the index for XML data type column in postgreSQL

Thank you so much for all your responses. I just tried with Hash, GIN etc But it didn't worked. And I think it is because of "Xpath" expression which I used in the index create command. But is there any alternative way to change this Xpath? Since I need to parse the XML as there is no other

Re: Query performance going from Oracle to Postgres

On Thu, Sep 7, 2023 at 3:48 AM David Rowley wrote: > On Thu, 7 Sept 2023 at 19:17, Peter Geoghegan wrote: > > It seems likely that the problem here is that some of the predicates > > appear as so-called "Filter:" conditions, as opposed to true index > > quals. > > hmm, if that were true we'd see

Re: Will PostgreSQL 16 supports native transparent data encryption ?

Greetings, * Matthias Apitz (g...@unixarea.de) wrote: > message from Stephen Frost mailto:sfr...@snowman.net> > > * Ron (ronljohnso...@gmail.com ) wrote: > > > On 8/21/23 18:49, Bruce Momjian wrote: > > > > On Mon, Aug 21, 2023 at 07:02:46PM +0300, Mostafa Fathy

Re: Huge input lookup exception when trying to create the index for XML data type column in postgreSQL

Erik Wienhold writes: > On 07/09/2023 21:09 CEST Tom Lane wrote: >> There is no such string anywhere in the Postgres source code; >> furthermore, if someone tried to add such an error, it'd get rejected >> (I hope) as not conforming to our style guidelines. I thought maybe >> it's coming from

Re: Huge input lookup exception when trying to create the index for XML data type column in postgreSQL

On Thu, Sep 7, 2023 at 12:28 PM Sai Teja wrote: > Here we’re using Xpath expression to create the index since postgreSQL > directly does not support comparison methods. So, we decided to use Xpath > expression. But while creating the index as I mentioned above we’re facing > the issue with Huge

Re: Huge input lookup exception when trying to create the index for XML data type column in postgreSQL

On 07/09/2023 21:09 CEST Tom Lane wrote: > Sai Teja writes: > > We have one table which is storing XML data with 30k records and stores > > huge amount of data. > > We are trying to create the index for this column in the table. But, we’re > > getting “Huge input Lookup error” during creation

Re: Huge input lookup exception when trying to create the index for XML data type column in postgreSQL

Sai Teja writes: > We have one table which is storing XML data with 30k records and stores > huge amount of data. > We are trying to create the index for this column in the table. But, we’re > getting “Huge input Lookup error” during creation of Index. There is no such string anywhere in the

Re: Only getting few records inserted from millions

On 07/09/2023 19:14 CEST Anthony Apollis wrote: > The problem is that I am only getting 19 rows inserted into my destination > table. My source has over 5 million rows. What am I doing wrong? Few ideas: * Column dim."IMETA_Entity_Mapping"."Entity_Secondary_Key" allows NULL but the join

Huge input lookup exception when trying to create the index for XML data type column in postgreSQL

Hi All, We have one table which is storing XML data with 30k records and stores huge amount of data. We are trying to create the index for this column in the table. But, we’re getting “Huge input Lookup error” during creation of Index. Please check the below command which is used to create the

Only getting few records inserted from millions

Please assist. I am retrieving data from SAP BW using SSIS. The data is loaded into: CREATE TABLE IF NOT EXISTS system."IMETA_ZTRB_MP$F_ZTBR_TA_BW" ( "Company_Code" character varying(4) COLLATE pg_catalog."default", "Posting_Period" character varying(7) COLLATE pg_catalog."default",

Re: Will PostgreSQL 16 supports native transparent data encryption ?

Greetings, * Ron (ronljohnso...@gmail.com) wrote: > On 8/24/23 14:08, Stephen Frost wrote: > > * Ron (ronljohnso...@gmail.com) wrote: > > > On 8/21/23 18:49, Bruce Momjian wrote: > > > > On Mon, Aug 21, 2023 at 07:02:46PM +0300, Mostafa Fathy wrote: > > > > > It is mentioned here  > > > > >

Re: listening on an address other than 'localhost'?

On 9/6/23 12:23, Johnson, Bruce E - (bjohnson) wrote: per the documentation to listen for client connections on a given IP address you set listen_addresses to a commaspearated list of IP addresses in postgresql.conf #listen_addresses = 10.128.206.109# what IP address(es) to listen on; #

Feedback on supporting AI queries in Postgres with EvaDB

Greetings! We are developing the EvaDB query engine [https://github.com/georgia-tech-db/evadb] for supporting AI queries in Postgres. Our goal is to assist software developers in building AI-powered apps with SQL. EvaDB allows querying data with AI models in this way: — Convert the super

Re: ERROR: stack depth limit exceeded

On Thu, 7 Sept 2023 at 08:45, gzh wrote: > but is there a good way to find out which SQL statements have issues without > having to run all SQL statements, as it would be too expensive? Does your postgresql server log not contain the error with the statement at issue? Geoff

Re: ERROR: stack depth limit exceeded

gzh writes: > I upgraded the version of PostgreSQL from 12.13 to 12.16. > If multiple subqueries or a large number of UNION ALL were used, > the previously unseen error message "ERROR: stack depth limit exceeded" will > appear after upgrading the version. Please provide a self-contained

Re: postgreSQL UPPER Method is converting the character "µ" into "M"

On 9/6/23 11:22, Helmut Bender wrote: Am 06.09.23 um 16:04 schrieb Sai Teja: In my local it is windows OS and locale is English_united_states.1252 and in local it is converting as expected ( testµ into TESTµ) You wrote PostgreSQL is hosted on an utf-8 system. That's why it's working

Re: Query performance going from Oracle to Postgres

On Thu, 7 Sept 2023 at 19:17, Peter Geoghegan wrote: > It seems likely that the problem here is that some of the predicates > appear as so-called "Filter:" conditions, as opposed to true index > quals. hmm, if that were true we'd see "Rows Removed by Filter" in the explain analyze. I think all

ERROR: stack depth limit exceeded

Hi, I upgraded the version of PostgreSQL from 12.13 to 12.16. If multiple subqueries or a large number of UNION ALL were used, the previously unseen error message "ERROR: stack depth limit exceeded" will appear after upgrading the version. I understand that increasing the value of

Re: listening on an address other than 'localhost'?

On 06/09/2023 21:23 CEST Johnson, Bruce E - (bjohnson) wrote: > Sep 6 19:06:01 dhbpostgres postgresql@15-main[1538]: 2023-09-06 19:06:01.181 > GMT [1543] LOG: syntax error in file > "/etc/postgresql/15/main/postgresql.conf" line 63, near token ".206" > > #listen_addresses = 10.128.206.109#

Re: listening on an address other than 'localhost'?

> On 6 Sep 2023, at 21:23, Johnson, Bruce E - (bjohnson) > wrote: > What am I missing? (postgresql 15.4 running on Ubuntu 22.04), installed via > postgresql.org apt repo. The value should be within '', so listen_addresses = '10.128.206.109' should work just fine. -- Daniel Gustafsson

Re: postgreSQL UPPER Method is converting the character "µ" into "M"

Am 06.09.23 um 16:04 schrieb Sai Teja: In my local it is windows OS and locale is English_united_states.1252 and in local it is converting as expected ( testµ into TESTµ) You wrote PostgreSQL is hosted on an utf-8 system. That's why it's working different. And be careful: the M isn't the

listening on an address other than 'localhost'?

per the documentation to listen for client connections on a given IP address you set listen_addresses to a commaspearated list of IP addresses in postgresql.conf That line is commented out in the default conf file, when I uncomment it, and add the address, then do sudo systemctl restart