Re: is JIT available

2020-07-28 Thread David Rowley
On Wed, 29 Jul 2020 at 00:26, Scott Ribe wrote: > But does compilation with JIT enable and LLVM dev tools mean that all the > LLVM compilation/optimization is built into the PG binaries, or does it > require LLVM presence on the machine where deployed? And if so, does the > function take that

Re: determine what column(s) form the primary key, in C extention

2020-07-28 Thread David Rowley
On Wed, 29 Jul 2020 at 03:45, alex maslakov wrote: > int i = -1; > while ((i = bms_next_member(pkattnos , i)) >= 0) { > /* do stuff with i */ > /* you'll need to use i - FirstLowInvalidHeapAttributeNumber to > get the pg_attribute.attnum */ > > > elog(INFO,

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Shaozhong SHI
On Tue, 28 Jul 2020 at 22:43, Michael Lewis wrote: > Many thanks. Is this way correct? I am learning what is meant by 'top >> posting'. >> > > Yes. > > On the subject of your settings, I don't see anything for work_mem, > random_page_cost and other commonly tuned parameters. That would be a

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Michael Lewis
> > Many thanks. Is this way correct? I am learning what is meant by 'top > posting'. > Yes. On the subject of your settings, I don't see anything for work_mem, random_page_cost and other commonly tuned parameters. That would be a good start. What sort of machine specs are there for Postgres

Re: bad JIT decision

2020-07-28 Thread Andres Freund
Hi, On 2020-07-28 14:07:48 -0700, Andres Freund wrote: > (I'm rebasing my tree that tries to reduce the overhead / allow caching > / increase efficiency to current PG, but it's a fair bit of work) FWIW, I created a demo workload for this, and repro'ed the issue with that. Those improvements does

Re: Is upper_inc ever true for dateranges?

2020-07-28 Thread Ken Tanzer
On Tue, Jul 28, 2020 at 2:24 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, Jul 28, 2020 at 2:19 PM Ken Tanzer wrote: > >> So here's my question. Will the upper_inc function always return false >> for a non-null daterange? And if so, what's the point of the function? >>

Re: Is upper_inc ever true for dateranges?

2020-07-28 Thread David G. Johnston
On Tue, Jul 28, 2020 at 2:19 PM Ken Tanzer wrote: > So here's my question. Will the upper_inc function always return false > for a non-null daterange? And if so, what's the point of the function? > And/or is it different for other kinds of ranges? > Ranges over discrete types are always

Is upper_inc ever true for dateranges?

2020-07-28 Thread Ken Tanzer
Hi. Regardless of how I specify a daterange, it is converted to inclusive lower bound, exclusive upper bound ('[)'): SELECT daterange('2019-01-01','2020-01-01','(]') AS range; range - [2019-01-02,2020-01-02) So here's my question. Will the upper_inc function

Re: bad JIT decision

2020-07-28 Thread Andres Freund
Hi, On 2020-07-28 11:54:53 +1200, David Rowley wrote: > Is there some reason that we can't consider jitting on a more granular > basis? There's a substantial "constant" overhead of doing JIT. And that it's nontrival to determine which parts of the query should be JITed in one part, and which

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Shaozhong SHI
On Tue, 28 Jul 2020 at 20:36, Gavin Flower wrote: > On 29/07/2020 03:51, Shaozhong SHI wrote: > > Hi, > > > > Please find the result of select name, setting, source from > > pg_settings where source <> 'default'; > > > > Regards, > > > > Shao > > > > > > > > On Tue, 28 Jul 2020 at 16:42, Michael

Re: bad JIT decision

2020-07-28 Thread Tom Lane
Andres Freund writes: > On 2020-07-27 19:02:56 -0400, Alvaro Herrera wrote: >>> I don't quite understand why is it that a table with 1000 partitions >>> means that JIT compiles the thing 1000 times. Sure, it is possible that >>> some partitions have a different column layout, but it seems an

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Gavin Flower
On 29/07/2020 03:51, Shaozhong SHI wrote: Hi, Please find the result of select name, setting, source from pg_settings where source <> 'default'; Regards, Shao On Tue, 28 Jul 2020 at 16:42, Michael Lewis > wrote: On Tue, Jul 28, 2020 at 7:59 AM Shaozhong

Re: Need free PG odbc driver for Windows 10

2020-07-28 Thread Adrian Klaver
On 7/28/20 9:40 AM, David Gauthier wrote: Hi: I need a free odbc driver for PG to be installed on Windows 10 that my user community can easily install.  By "easily install" I mean no binaries, no zipped file, etc... just point-click-install (with the usual confirmations and accepting default

Re: Need free PG odbc driver for Windows 10

2020-07-28 Thread Thomas Kellerer
David Gauthier schrieb am 28.07.2020 um 18:40: Hi: I need a free odbc driver for PG to be installed on Windows 10 that my user community can easily install. By "easily install" I mean no binaries, no zipped file, etc... just point-click-install (with the usual confirmations and accepting

Re: bad JIT decision

2020-07-28 Thread Andres Freund
Hi, On 2020-07-27 19:02:56 -0400, Alvaro Herrera wrote: > On 2020-Jul-27, Scott Ribe wrote: > > > > On Jul 27, 2020, at 4:00 PM, Alvaro Herrera > > > wrote: > > > > > > I don't quite understand why is it that a table with 1000 partitions > > > means that JIT compiles the thing 1000 times.

Re: Need free PG odbc driver for Windows 10

2020-07-28 Thread Igor Korot
Hi, On Tue, Jul 28, 2020 at 11:40 AM David Gauthier wrote: > > Hi: > > I need a free odbc driver for PG to be installed on Windows 10 that my user > community can easily install. By "easily install" I mean no binaries, no > zipped file, etc... just point-click-install (with the usual

Need free PG odbc driver for Windows 10

2020-07-28 Thread David Gauthier
Hi: I need a free odbc driver for PG to be installed on Windows 10 that my user community can easily install. By "easily install" I mean no binaries, no zipped file, etc... just point-click-install (with the usual confirmations and accepting default destinations for the code and such). Devart

Re: determine what column(s) form the primary key, in C extention

2020-07-28 Thread alex maslakov
I'm emailing it to the 'general' list. (1) This:     int i = -1;     while ((i = bms_next_member(pkattnos , i)) >= 0) {     /* do stuff with i */     /* you'll need to use i - FirstLowInvalidHeapAttributeNumber to get the pg_attribute.attnum */     elog(INFO, "bms_next_member

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Michael Lewis
On Tue, Jul 28, 2020 at 7:59 AM Shaozhong SHI wrote: > Hi, Gavin, > > PostgreSQL Version - 10.11. PostGIS Version - 2.4.7. Operating System - > Red Hat Enterprise Linux 7.7 . > > That is all I know at the moment. > > As I understand, our IT staff is building another one to sit on Azure. >

Re: Out of memory with "create extension postgis"

2020-07-28 Thread Daniel Westermann (DWE)
>>> "Daniel Westermann (DWE)" writes: The process eats all the available memory and finally dies: # create extension postgis; ERROR: out of memory DETAIL: Failed on request of size 8265691 in memory context "PortalContext". Time: 773569.877 ms (12:53.570) >>

Re: Out of memory with "create extension postgis"

2020-07-28 Thread Tom Lane
"Daniel Westermann (DWE)" writes: >> "Daniel Westermann (DWE)" writes: >>> The process eats all the available memory and finally dies: >>> # create extension postgis; >>> ERROR: out of memory >>> DETAIL: Failed on request of size 8265691 in memory context >>> "PortalContext". >>> Time:

Re: Out of memory with "create extension postgis"

2020-07-28 Thread Daniel Westermann (DWE)
>"Daniel Westermann (DWE)" writes: >> we have a very strange behavior on PostgreSQL 12.3 when we try to create the >> extension postgis. Postgres and postgis have both been installed from >> packages: >> ... >> The process eats all the available memory and finally dies: >> # create extension

Re: Out of memory with "create extension postgis"

2020-07-28 Thread Tom Lane
"Daniel Westermann (DWE)" writes: > we have a very strange behavior on PostgreSQL 12.3 when we try to create the > extension postgis. Postgres and postgis have both been installed from > packages: > ... > The process eats all the available memory and finally dies: > # create extension postgis;

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Shaozhong SHI
Hi, Gavin, PostgreSQL Version - 10.11. PostGIS Version - 2.4.7. Operating System - Red Hat Enterprise Linux 7.7 . That is all I know at the moment. As I understand, our IT staff is building another one to sit on Azure. Regards, Shao On Tue, 28 Jul 2020 at 12:31, Gavin Flower wrote: > On

Re: is JIT available

2020-07-28 Thread Scott Ribe
> On Jul 27, 2020, at 9:33 PM, Tom Lane wrote: > > The general, non-hacker meaning of "jit is enabled" would seem to > be pretty much what this function is already doing; and for that > matter, the same can be said for "JIT compilation is available". > We need something that's less

Re: is JIT available

2020-07-28 Thread Scott Ribe
> On Jul 27, 2020, at 6:04 PM, David Rowley wrote: > > "returns true if jit is enabled and JIT compilation is available in > this session (see Chapter 31)." That is clearer. I didn't submit a suggestion myself because I'm not clear on the actual circumstances. I know it won't be available if:

Re: Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Gavin Flower
On 28/07/2020 22:54, Shaozhong SHI wrote: It has been found that issues occur when Big Data is being handled with PostGIS. Typically, queries can be killed by the system or memory is out.  Often, queries can be very slow.  Sometimes, it will take days or weeks to complete. What are the best

Re: is JIT available

2020-07-28 Thread David Rowley
On Tue, 28 Jul 2020 at 15:55, David Rowley wrote: > > On Tue, 28 Jul 2020 at 15:33, Tom Lane wrote: > > > > David Rowley writes: > > > Maybe this would be better? > > > > > "returns true if jit is enabled and JIT compilation is available in > > > this session (see Chapter 31)." > > > > The

Issues of slow running queries when dealing with Big Data

2020-07-28 Thread Shaozhong SHI
It has been found that issues occur when Big Data is being handled with PostGIS. Typically, queries can be killed by the system or memory is out. Often, queries can be very slow. Sometimes, it will take days or weeks to complete. What are the best approaches and means for improving the

Out of memory with "create extension postgis"

2020-07-28 Thread Daniel Westermann (DWE)
Hi, we have a very strange behavior on PostgreSQL 12.3 when we try to create the extension postgis. Postgres and postgis have both been installed from packages: postgresql12-server-12.3-5PGDG postgis30_12-3.0.1-5.rhel7 The OS is RedHat 7.7. Creating other extensions works fine, we only see