2018-01-12 9:03 GMT+01:00 Nandakumar M :
> Hello Jeff,
>
> Thanks for the insights.
>
> >Don't keep closing and reopening connections.
>
> Even if I close a connection and open a new one and execute the same
> query, the planning time is considerably less than the first time. Only
> when I restart
2018-01-31 14:15 GMT+01:00 Vitaliy Garnashevich :
> I've tried to re-run the test for some specific values of
> effective_io_concurrency. The results were the same.
>
> That's why I don't think the order of tests or variability in "hardware"
> performance affected the results.
>
AWS uses some int
2018-03-02 14:49 GMT+01:00 Nandakumar M :
> Hi,
>
> https://heapanalytics.com/blog/engineering/running-10-
> million-postgresql-indexes-in-production
>
> From the link shared above, it looks like what Meenatchi has done should
> work.
>
It can be different situation, there are not specified index
2018-03-02 15:29 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-02 14:49 GMT+01:00 Nandakumar M :
>
>> Hi,
>>
>> https://heapanalytics.com/blog/engineering/running-10-millio
>> n-postgresql-indexes-in-production
>>
>> From the link shared above, it l
2018-03-21 13:03 GMT+01:00 Gary Cowell :
> We are trying to implement postgresql code to load a large object into
> a postgresql bytea in chunks to avoid loading the file into memory in
> the client.
>
> First attempt was to do
>
> update build_attachment set chunk = chunk || newdata ;
>
> this di
2018-03-21 13:56 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-21 13:03 GMT+01:00 Gary Cowell :
>
>> We are trying to implement postgresql code to load a large object into
>> a postgresql bytea in chunks to avoid loading the file into memory in
>> the client.
>>
>
.html
you can use lo_write function
> On 21 March 2018 at 12:59, Pavel Stehule wrote:
> >
> >
> > 2018-03-21 13:56 GMT+01:00 Pavel Stehule :
> >>
> >>
> >>
> >> 2018-03-21 13:03 GMT+01:00 Gary Cowell :
> >>>
> >>> W
Hi
2018-04-16 22:42 GMT+02:00 Hackety Man :
> *A description of what you are trying to achieve and what results you
> expect.:*
>
> My end goal was to test the execution time difference between using an
> IF(SELECT COUNT(*)...) and an IF EXISTS() when no indexes were used and
> when a string matc
2018-04-17 12:52 GMT+02:00 Tomas Vondra :
>
>
> On 04/17/2018 07:17 AM, Pavel Stehule wrote:
>
>> Hi
>>
>> 2018-04-16 22:42 GMT+02:00 Hackety Man > hackety...@gmail.com>>:
>>
>> ...
>>
> >
>
>> A support of parallel query
>>>
>>>
>>> Right. I was more wondering why it switched over to a generic plan, as
>>> you've stated, like clockwork starting with the 6th execution run.
>>>
>>>
>> That's a hard-coded value. The first 5 executions are re-planned using
>> the actual parameter values, and then we try generating a g
Hi
so 14. 1. 2023 v 15:51 odesílatel hehaoc...@hotmail.com <
hehaoc...@hotmail.com> napsal:
> The default is enable_bitmapscan on. However, TPC-H.query17 get slower
> running on my NVMe SSD (WD SN850) after switching on the parameter: latency
> drop from 9secs to 16secs. During a B-tree Index Sc
Hi
pá 10. 2. 2023 v 19:53 odesílatel Adithya Kumaranchath <
akumaranch...@live.com> napsal:
> Hi all,
>
> I am running a simple test and am curious to know why a difference in
> execution times between PostgreSQL 12 vs PostgreSQL 15.
>
> *I have this function:*
> CREATE function test() returns i
Hi
> Please, don't send screenshots - we believe you :-)
>
> Your code can be little bit faster if you use flag IMMUTABLE
>
> There were more patches that reduced the overhead of expression's
> evaluation in PL/pgSQL.
>
> History
>
> https://github.com/postgres/postgres/commits/master/src/pl/plpg
po 13. 2. 2023 v 22:22 odesílatel Andres Freund napsal:
> Hi,
>
> On 2023-02-10 20:45:39 +0100, Pavel Stehule wrote:
> > But for significant improvements it needs some form of JIT (Postgres has
> JIT
> > for SQL expressions, but it is not used for PLpgSQL expressions).
Hi
čt 1. 6. 2023 v 8:53 odesílatel Laurenz Albe
napsal:
> On Thu, 2023-06-01 at 03:36 +, James Pang (chaolpan) wrote:
> > PG V14.8-1 , client using Postgresql JDBC driver we found 40MB process
> memory per
> > backend, from Operating system and memorycontext dump “Grand total:”,
> both mache
hedPlanSource: 2048 total in 2 blocks; 200 free (0 chunks); 1848
> used: xxx
> CachedPlanQuery: 2048 total in 2 blocks; 704 free (0 chunks); 1344
> used
>
> Thanks,
>
> James
>
> -Original Message-
> From: Laurenz Albe
> Sent: Thursday, June 1, 2
Hi
út 13. 6. 2023 v 11:21 odesílatel James Pang (chaolpan)
napsal:
> Hi,
>
> When join two table on multiple columns equaljoin, rows estimation
> always use selectivity = multiplied by distinct multiple individual
> columns, possible to use extended n-distinct statistics on multiple
> colu
út 13. 6. 2023 v 15:50 odesílatel Tom Lane napsal:
> "James Pang (chaolpan)" writes:
> > Looks like it's the function "regexp_replace" volatile and
> restrict=false make the difference, we have our application role with
> default search_path=oracle,$user,public,pg_catalog.
> > =#se
út 13. 6. 2023 v 16:17 odesílatel Pavel Stehule
napsal:
>
>
> út 13. 6. 2023 v 15:50 odesílatel Tom Lane napsal:
>
>> "James Pang (chaolpan)" writes:
>> > Looks like it's the function "regexp_replace" volatile and
>> restrict=fal
ine to do
> that ?
>
I didn't release 4.4, but it is available on github. Orafce supports
online upgrades
Hot fix can be execution of
https://github.com/orafce/orafce/blob/master/orafce--4.3--4.4.sql file
Regards
Pavel
>
> Thanks,
>
>
>
> James
>
>
>
>
po 28. 8. 2023 v 13:00 odesílatel Les napsal:
>
>
>>
>> =# select * from pgstatindex('media.idx_block_unused');
>> version | tree_level | index_size | root_block_no | internal_pages |
>> leaf_pages | empty_pages | deleted_pages | avg_leaf_density |
>> leaf_fragmentation
>>
>> -+-
Hi
čt 29. 2. 2024 v 15:28 odesílatel James Pang
napsal:
> Hi,
>we create statistics (dependencies,distinct) on (cccid,sssid); with
> real bind variables , it make good plan of Hash join , but when it try to
> generic plan, it automatically convert to Nestloop and then very poor sql
> perfo
po 17. 6. 2024 v 11:35 odesílatel Julius Tuskenis
napsal:
> Dear Postgresql performance guru,
>
> For some reason on our client server a function written in SQL language
> executes *100 times slower* than the one written in plpgsql...
>
> After updating to "PostgreSQL 12.18, compiled by Visual C+
po 17. 6. 2024 v 15:55 odesílatel Julius Tuskenis
napsal:
> On 2024-06-17 15:59, Philip Semanchuk wrote:
>
> On Jun 17, 2024, at 5:35 AM, Julius Tuskenis
> wrote:
>
>
> Isn't PosgreSQL supposed to inline simple SQL functions that are stable or
> immutable?
>
> Postgres inlines SQL functions u
Hi
po 1. 7. 2024 v 12:10 odesílatel David Rowley napsal:
> On Mon, 1 Jul 2024 at 21:45, James Pang wrote:
> >Buffers: shared hit=110246 <<< here planning need access a
> lot of buffers
> > Planning Time: 81.850 ms
> > Execution Time: 0.034 ms
> >
> >could you help why planning
2018-07-30 1:00 GMT+02:00 Tom Lane :
> David Rowley writes:
> > On 29 July 2018 at 17:38, Dinesh Kumar wrote:
> >> I found performance variance between accessing int1 and int200 column
> which
> >> is quite large.
>
> > Have a look at slot_deform_tuple and heap_deform_tuple. You'll see
> > that
2018-07-30 13:19 GMT+02:00 Jeff Janes :
> On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule
> wrote:
>
>> 2018-07-30 1:00 GMT+02:00 Tom Lane :
>>
>>> David Rowley writes:
>>> > On 29 July 2018 at 17:38, Dinesh Kumar wrote:
>>> >> I fou
so 6. 10. 2018 v 11:57 odesílatel ROS Didier napsal:
> Hi
>
> I would like to submit the following problem to the PostgreSQL community.
> In my company, we have data encryption needs.
> So I decided to use the following procedure :
>
>
>
> (1)Creating a table with a bytea type column to store
pá 30. 11. 2018 v 15:37 odesílatel Sanyo Moura
napsal:
> Hello again,
>
> At the moment, I've got a palliative solution that has significantly
> reduced my planning time.
> What I did was nest the partitions by creating sub partitions.
> That way, my 730 partitions (2 years of data) were partitio
út 29. 1. 2019 v 19:29 odesílatel Bob Jolliffe
napsal:
> The following is output from analyzing a simple query on a table of
> 13436 rows on postgresql 10, ubuntu 18.04.
>
> explain analyze select * from chart order by name;
>QUERY PLAN
>
> ---
Hi
po 25. 2. 2019 v 11:37 odesílatel Tobias Gierke <
tobias.gie...@code-sourcery.de> napsal:
> Hi,
>
> Recently we started seeing the Linux OOM killer kicking in and killing
> PostgreSQL processes on one of our development machines.
>
> The PostgreSQL version we're using was compiled by us, is ru
po 8. 4. 2019 v 16:11 odesílatel Krzysztof Plocharz
napsal:
> Hi
>
> We have some very strange query planning problem. Long story short it
> takes 67626.278ms just to plan. Query execution takes 12ms.
>
> Query has 7 joins and 2 subselects.
> It looks like the issue is not deterministic, sometime
po 8. 4. 2019 v 16:55 odesílatel Krzysztof Plocharz
napsal:
>
>
> On 2019/04/08 16:42, Justin Pryzby wrote:
> > On Mon, Apr 08, 2019 at 04:33:34PM +0200, Pavel Stehule wrote:
> >> po 8. 4. 2019 v 16:11 odes�latel Krzysztof Plocharz <
> ploch...@9livesdata.com>
Hi
ne 18. 8. 2019 v 8:57 odesílatel Mariel Cherkassky <
mariel.cherkas...@gmail.com> napsal:
> Hey,
> I upgraded my pg9.6 cluster to pg11.2.
> As it seems after the upgrade the duration of the same flow in my
> application raised from 13 minutes to 19 minutes.
>
> The test I did :
> 1.reset pg_st
út 20. 8. 2019 v 17:12 odesílatel Felix Geisendörfer
napsal:
> Hi all,
>
> today I debugged a query that was executing about 100x slower than
> expected, and was very surprised by what I found.
>
> I'm posting to this list to see if this might be an issue that should be
> fixed in PostgreSQL itse
čt 22. 8. 2019 v 3:11 odesílatel Jeff Janes napsal:
> On Tue, Aug 20, 2019 at 11:12 AM Felix Geisendörfer
> wrote:
> ...
>
>
>> [1] My actual query had bad estimates for other reasons (GIN Index), but
>> that's another story. The query above was of course deliberately designed
>> to have bad es
Hi
čt 26. 9. 2019 v 9:55 odesílatel Joao Junior napsal:
> Hi,
> Is this necessary to run analyze on a slave using streaming replication
> after promotion??
>
No - column statistics are come from master - and are persistent - promote
change nothing.
Pavel
Hi
út 22. 10. 2019 v 14:28 odesílatel Joao Junior napsal:
> Hi,
> I am not sure if here is the best place to post this.
> I would like to know why max_connections parameter can't be changed
> without a restart. I know that it is a postmaster's context parameter.
> Which PostgreSQL's subsystems
po 4. 11. 2019 v 6:17 odesílatel David Wheeler
napsal:
> >To see this issue, you have to have recently
> >inserted or deleted a bunch of extremal values of the indexed join-key
> >column. And the problem only persists until those values become known
> >committed-good, or known de
pá 22. 11. 2019 v 12:46 odesílatel Sterpu Victor napsal:
> No rows should be returned, DB is empty.
> I'm testing now on a empty DB trying to find out how to improve this.
>
> In this query I have 3 joins like this:
>
> SELECT t1.id, t2.valid_from
> FROM t1
> JOIN t2 ON (t1.id_t1 = t1.id)
> LEFT
09 ms: I deleted the line "LIMIT 20 OFFSET 0"
> Changing this line in the final query is not an option, can I do something
> else to fix this?
>
it looks like planner bug. It's strange so LIMIT OFFSET 0 can increase 10x
planning time
Pavel
> Thank you.
>
>
&g
pá 22. 11. 2019 v 18:37 odesílatel Luís Roberto Weck <
luisrobe...@siscobra.com.br> napsal:
> Hey,
>
> I'm trying to figure out why Postgres is choosing a Hash Join over a
> Nested Loop in this query:
>
> SELECT T1.PesID, T1.PesNom, T1.PesValSal, T1.PesCPFCNPJ, T2.CarAti,
> T1.CarCod, T1.EmpCod,
>
pá 22. 11. 2019 v 19:42 odesílatel Luís Roberto Weck <
luisrobe...@siscobra.com.br> napsal:
> Em 22/11/2019 14:55, Pavel Stehule escreveu:
>
>
>
> pá 22. 11. 2019 v 18:37 odesílatel Luís Roberto Weck <
> luisrobe...@siscobra.com.br> napsal:
>
>> Hey,
>>
po 16. 12. 2019 v 14:02 odesílatel Mariel Cherkassky <
mariel.cherkas...@gmail.com> napsal:
> I see, thank u !
> Maybe I didnt see big difference because most of my tables arent so big.
> My db`s size is 17GB and the largest table contains about 20M+ records.
>
Postgres 12 has enabled JIT by defa
út 17. 12. 2019 v 11:45 odesílatel Kaijiang Chen
napsal:
> I'm using postgres 9.4.17 on centos 7.
> I check the running queries with the following SQL:
> SELECT
> procpid,
> start,
> now() - start AS lap,
> current_query
> FROM
> (SELECT
> backendid,
> pg_stat_
Hi
po 17. 2. 2020 v 17:36 odesílatel Laurenz Albe
napsal:
> On Mon, 2020-02-17 at 15:03 +, Lars Aksel Opsahl wrote:
> > I have tested in branch (
> https://github.com/larsop/resolve-overlap-and-gap/tree/add_postgis_topology_using_func
> )
> > where I use only have functions and no procedures
po 17. 2. 2020 v 19:23 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > po 17. 2. 2020 v 17:36 odesílatel Laurenz Albe >
> > napsal:
> >> Either use shorter transactions, or start fewer subtransactions.
>
> > it is interesting topic, but I don&#x
út 18. 2. 2020 v 18:27 odesílatel Laurenz Albe
napsal:
> On Mon, 2020-02-17 at 19:41 +0100, Pavel Stehule wrote:
> > I tested
> >
> > CREATE OR REPLACE FUNCTION public.fx(integer)
> > RETURNS void
> > LANGUAGE plpgsql
> > AS $function$
> >
po 30. 3. 2020 v 8:47 odesílatel Silvio Moioli napsal:
> Dear list,
>
> here is a pretty contrived case where increasing work_mem produces a worse
> plan, with much worse overall query time. I wonder why that is the case.
>
>
> Problem: INSERTing a thousand new rows in a table which can easily ha
po 30. 3. 2020 v 10:12 odesílatel Silvio Moioli napsal:
> On 3/30/20 8:56 AM, Pavel Stehule wrote:
> > please, can you send explain in text form?
>
> Sure. With work_mem = 80MB:
>
>
po 30. 3. 2020 v 15:09 odesílatel Silvio Moioli napsal:
> On 3/30/20 12:12 PM, Pavel Stehule wrote:
> > Do you have some planner variables changed - like seq_page_cost?
>
> That one was not changed but another one is - cpu_tuple_cost (to 0.5).
> Indeed bringing it back t
>
> Is that an unreasonable value? For the sake of this discussison, I am
> targeting fairly average bare-metal SSD-backed servers with recent CPUs
> (let's say 3 year old maximum), with ample available RAM.
>
if you have SSD, then you can decrease RANDOM_PAGE_COST to 2 maybe 1.5. But
probably the
po 30. 3. 2020 v 18:02 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > po 30. 3. 2020 v 10:12 odesílatel Silvio Moioli napsal:
> >> -> Sort (cost=299108.00..300335.41 rows=490964 width=79)
> >> (actual time=6475.147..6494.111 rows=46260
po 30. 3. 2020 v 18:36 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > CTE scan has only 1100 rows, public.rhnpackagecapability has 490964
> rows.
> > But planner does hash from public.rhnpackagecapability table. It cannot
> be
> > very effective.
>
> [
Hi
It looks so in slow plan is some strange relations between subselects - the
slow plan looks like plan for correlated subquery, and it should be slow.
Minimally you miss a index on column
jtemp1c37l3b_baseline_windows_after_inclusion.uuid
Hi
so 30. 5. 2020 v 9:37 odesílatel sugnathi hai napsal:
> Hi ,
>
> Can you help to tune the below plan
>
> Limit (cost=0.87..336777.92 rows=100 width=57) (actual
> time=599302.173..599481.552 rows=100 loops=1) Buffers: shared hit=78496066
> -> Nested Loop (cost=0.87..11005874.67 rows=3268 width
pá 5. 6. 2020 v 12:07 odesílatel Krzysztof Olszewski
napsal:
> I have problem with one of my Postgres production server. Server works
> fine almost always, but sometimes without any increase of transactions or
> statements amount, machine gets stuck. Cores goes up to 100%, load up to
> 160%. When
so 13. 6. 2020 v 6:34 odesílatel Justin Pryzby
napsal:
> On Fri, Jun 12, 2020 at 11:11:09PM -0400, Tom Lane wrote:
> > regrog writes:
> > > I'm facing performance issues migrating from postgres 10 to 12 (also
> from 11
> > > to 12) even with a new DB.
> > > The simple query: select * from my_con
so 13. 6. 2020 v 7:13 odesílatel Pavel Stehule
napsal:
>
>
> so 13. 6. 2020 v 6:34 odesílatel Justin Pryzby
> napsal:
>
>> On Fri, Jun 12, 2020 at 11:11:09PM -0400, Tom Lane wrote:
>> > regrog writes:
>> > > I'm facing performance issues mi
so 13. 6. 2020 v 7:15 odesílatel Pavel Stehule
napsal:
>
>
> so 13. 6. 2020 v 7:13 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> so 13. 6. 2020 v 6:34 odesílatel Justin Pryzby
>> napsal:
>>
>>> On Fri, Jun 12, 2020 at 11:11:09PM -0400, To
Hi
po 24. 8. 2020 v 18:40 odesílatel Dirk Krautschick <
dirk.krautsch...@trivadis.com> napsal:
> Hi,
>
> are there any nice rules of thumb about capacity planning in relation the
> expected
> amount of transactions or request per second?
>
> For example, if I have around 100 000 transactions per
út 8. 9. 2020 v 15:33 odesílatel aditya desai napsal:
> Hi,
> We have an application where one of the APIs calling queries(attached) is
> spiking the CPU to 100% during load testing.
> However, queries are making use of indexes(Bitmap Index and Bitmap Heap
> scan though). When run separately on D
út 15. 9. 2020 v 1:11 odesílatel Robert Treat napsal:
> Howdy folks,
>
> Recently i've run into a problem where autoanalyze is causing a query
> plan to flip over to using an index which is about 10x slower, and the
> problem is fixed by running an alayze manually. some relevant info:
>
> UPDATE
Hi
pá 9. 10. 2020 v 7:40 odesílatel Kanninen Anssi EXT <
anssi.kanni...@digia.com> napsal:
> Hi there!
>
>
>
> Is there any way to use indexes with XMLTABLE-query to query XML type data?
>
> I've only managed to use text[] indexes with plain xpath queries. Is there
> any similar workaround for XM
út 20. 10. 2020 v 11:59 odesílatel Mats Julian Olsen
napsal:
> On Tue, Oct 20, 2020 at 9:50 AM David Rowley wrote:
>
>> On Tue, 20 Oct 2020 at 22:38, Mats Julian Olsen
>> wrote:
>> >
>> > The crux of our issue is that the query planner chooses a nested loop
>> join for this query. Essentially m
út 20. 10. 2020 v 13:09 odesílatel Mats Julian Olsen
napsal:
>
>
> On Tue, Oct 20, 2020 at 10:50 AM Pavel Stehule
> wrote:
>
>>
>>
>> út 20. 10. 2020 v 11:59 odesílatel Mats Julian Olsen <
>> m...@duneanalytics.com> napsal:
>>
>>
Hi
po 1. 3. 2021 v 15:59 odesílatel Jung, Jinho napsal:
> Andrew, Bob, Michael
>
> Thanks for the valuable feedback! Even with the default setting,
> PostgreSQL mostly showed good performance than other DBMSs. The reported
> queries are a very tiny portion among all executed queries (e.g., <0.00
út 2. 3. 2021 v 9:53 odesílatel Liu, Xinyu napsal:
>
>
>
>
>
>
>
>
>
>
> * Hello, We have 2 TPC-H queries which fetch the same tuples but have
> significant query execution time differences (4.3 times). We are sharing a
> pair of TPC-H queries that exhibit this performance difference: First
> que
so 3. 4. 2021 v 15:38 odesílatel aditya desai napsal:
> Hi,
> We migrated our Oracle Databases to PostgreSQL. One of the simple select
> query that takes 4 ms on Oracle is taking around 200 ms on PostgreSQL.
> Could you please advise. Please find query and query plans below. Gather
> cost seems h
so 3. 4. 2021 v 17:30 odesílatel aditya desai napsal:
> adding the group.
>
> aad_log_min_messages | warning
> | configuration file
> application_name | psql
>| client
> archive_command
so 3. 4. 2021 v 19:37 odesílatel aditya desai napsal:
> Hi Justin/Bruce/Pavel,
> Thanks for your inputs. After setting force_parallel_mode=off Execution
> time of same query was reduced to 1ms from 200 ms. Worked like a charm. We
> also increased work_mem to 80=MB. Thanks
>
super.
The too big m
st overloading. max_connection should
be 10-20 x CPU cores (for OLTP)
Regards
Pavel
> On Sat, Apr 3, 2021 at 11:12 PM Pavel Stehule
> wrote:
>
>>
>>
>> so 3. 4. 2021 v 19:37 odesílatel aditya desai
>> napsal:
>>
>>> Hi Justin/Bruce/Pavel,
>>>
Hi
čt 15. 4. 2021 v 15:45 odesílatel warst...@list.ru
napsal:
> Hi,
>
> Is there any way to set time that CURRENT_TIMESTAMP and/or now() will give
> next time? (We need it only for testing purposes so if there is any hack,
> cheat, etc. It will be fine)
>
This is a bad way - don't use now() in
pá 28. 5. 2021 v 21:39 odesílatel Ryan Bair napsal:
> The problem is the plan. The planner massively underestimated the number
> of rows arising from the _EN/_AM join.
>
> Usually postgres is pretty good about running ANALYZE as needed, but it
> might be a good idea to run it manually to rule tha
pá 4. 6. 2021 v 10:07 odesílatel Ayub Khan napsal:
>
> below query is slow even with no data
>
>
> explain ANALYZE
>
> WITH business AS( SELECT * FROM get_businessday_utc_f() start_date)
> SELECT ro.order_id,
> ro.date_time,
> round(ro.order_amount, 2) AS order_amount,
> b.branch_id
y=275230
When the most rows are removed in recheck, then the effectivity of the
index is not good
Pavel
>
> On Fri, Jun 4, 2021 at 11:23 AM Pavel Stehule
> wrote:
>
>>
>>
>> pá 4. 6. 2021 v 10:07 odesílatel Ayub Khan napsal:
>>
>>>
>>&
Hi
pá 30. 7. 2021 v 10:02 odesílatel Imre Samu napsal:
> Hi Daniel,
>
> side note:
>
> Maybe you can tune the "function" with some special query optimizer
> attributes:
> IMMUTABLE | STABLE | VOLATILE | PARALLEL SAFE
>
> so in your example:
> create or replace function f1(int) returns
Hi
pá 30. 7. 2021 v 9:12 odesílatel Daniel Westermann (DWE) <
daniel.westerm...@dbi-services.com> napsal:
> Hi,
>
> we have a customer which was migrated from Oracle to PostgreSQL 12.5 (I
> know, the latest version is 12.7). The migration included a lot of PL/SQL
> code. Attached a very simplifie
pá 30. 7. 2021 v 10:04 odesílatel Pavel Stehule
napsal:
> Hi
>
> pá 30. 7. 2021 v 10:02 odesílatel Imre Samu napsal:
>
>> Hi Daniel,
>>
>> side note:
>>
>> Maybe you can tune the "function" with some special query optimizer
>> attribut
pá 30. 7. 2021 v 10:12 odesílatel Daniel Westermann (DWE) <
daniel.westerm...@dbi-services.com> napsal:
>
> pá 30. 7. 2021 v 9:12 odesílatel Daniel Westermann (DWE) <
> daniel.westerm...@dbi-services.com> napsal:
>
> Hi,
>
> we have a customer which was migrated from Oracle to PostgreSQL 12.5 (I
>
Hi
st 11. 8. 2021 v 20:57 odesílatel aditya desai napsal:
> Hi,
> We are migrating Oracle to PostgreSQL. We need the equivalent of UTL_HTTP.
> How to invoke Web service from PostgreSQL.
>
> Also please let me know the PostgreSQL equivalents of below
> Oracle utilities..
>
> utl.logger,UTL_FILE,U
Hi
po 30. 8. 2021 v 2:44 odesílatel l...@laurent-hasson.com <
l...@laurent-hasson.com> napsal:
>
>
>
> At this point, I am not sure how to proceed except to rethink that
> toFloat() function and many other places where we use exceptions. We get
> such dirty data that I need a "safe" way to conver
Hi
> There is a CentOS8-stream version which solves the problem but I cannot
> use that in the office. I will probably have to wait for another month
> before OL8 has everything that I need in its repositories. Now, the
> question is what kind of an impact will running without llvm-jit have?
> Ac
út 11. 1. 2022 v 9:41 odesílatel Hüseyin Ellezer
napsal:
> Hello everyone,
>
> I am currently running queries with the same table structures in 2
> different virtual machines and 2 different versions. and I get results like
> below.
>
>
> Execution Query:
>
> select d.device_id from ats_devices d
AIN (ANALYZE, BUFFERS) SELECT ...
https://www.postgresql.org/docs/current/sql-explain.html
Regards
Pavel
> Best regards
>
> Pavel Stehule , 11 Oca 2022 Sal, 16:31 tarihinde
> şunu yazdı:
>
>>
>>
>> út 11. 1. 2022 v 9:41 odesílatel Hüseyin Ellezer
>> napsal:
&g
pá 4. 2. 2022 v 10:11 odesílatel Les napsal:
> Hello,
>
> I have a table that contains folders, and another one that contains files.
>
> Here are the table definitions. I have removed most of the columns because
> they are not important for this question. (There are lots of columns.)
>
> CREATE T
86 matches
Mail list logo
