On Tue, Jan 9, 2018 at 3:32 PM, Reddygari, Pavan wrote:
>
> A view got converted to postgresql, performance while querying the view in
> postgresql is 10X longer compared to oracle.
>
>FROM (item_attribute_value a
> JOIN item_attribute ON ((a.iav_iat_id = item_attribute.iat_id)))
> WHE
On Sun, Mar 25, 2018 at 12:00 AM, Laurenz Albe wrote:
> Peter wrote:
>> Given an arbitrary function fn(x) returning numeric.
>>
>> Question: how often is the function executed?
>> [...]
>> C.
>> select v.v,v.v from (select fn('const') as v) as v;
>>
>> Answer:
>> Once if declared VOLATILE.
>> Twic
On Thu, May 4, 2023 at 4:23 PM Thomas Munro wrote:
> On Fri, May 5, 2023 at 8:37 AM ProfiVPS Support
> wrote:
> > I feel like ANYTHING would be better than this. Even risking loosing
> _some_ of the latest data in case of a server crash (if it crashes we lose
> data anyways until restart, ofc w
On Mon, Sep 11, 2023 at 11:07 PM David Rowley wrote:
> On Tue, 12 Sept 2023 at 02:27, Tom Lane wrote:
> >
> > David Rowley writes:
> > > I'm not sure if you're asking for help here because you need planning
> > > to be faster than it currently is, or if it's because you believe that
> > > plann
On Mon, Oct 29, 2018 at 9:18 AM Uday Bhaskar V
wrote:
>
> Hi,
>
> I have searched in many postgres blogs for Sequential UUID generation, which
> can avoid Fragmentation issue.
>
> I did a POC(in postgres) with sequential UUID against Non sequential which
> has shown lot of different in space uti
On Thu, Nov 8, 2018 at 3:12 PM David Rowley
wrote:
>
> On 9 November 2018 at 08:35, Lincoln Swaine-Moore
> wrote:
> > My primary question is: why is this approach only possible (for data too
> > large for memory) when using NOT EXISTS, and not when using NOT IN?
> >
> > I understand that there is
On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> Looks like a lot of the difference being seen and the comments made
> about one being faster than the other are because one system is
> compressing *everything*, while PG (quite intentionally...) only
> compresses the data sometimes- once it
On Tue, Nov 20, 2018 at 10:43 AM Stephen Frost wrote:
>
> Greetings,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> > > Looks like a lot of the difference being seen and the comments made
> > > a
On Tue, Nov 20, 2018 at 11:28 AM Stephen Frost wrote:
>
> Greetings,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > On Tue, Nov 20, 2018 at 10:43 AM Stephen Frost wrote:
> > > * Merlin Moncure (mmonc...@gmail.com) wrote:
> > > > On Mon,
On Wed, Dec 12, 2018 at 6:54 AM Mariel Cherkassky <
mariel.cherkas...@gmail.com> wrote:
> Hey,
> I installed a new postgres 9.6 on both of my machines. I'm trying to
> measure the differences between the performances in each machine but it
> seems that the results arent accurate.
> I did 2 tests :
On Tue, Dec 11, 2018 at 10:01 AM Tom Lane wrote:
>
> Greg Clough writes:
> >>> 2018-12-10 19:11:56 IST 23647 LOG: received fast shutdown request
> >>> any idea what can cause it ?
>
> >> Something sent SIGINT to the postmaster.
>
> > My money is on the OoM (Out of Memory) killer.
>
> That usua
On Thu, Dec 27, 2018 at 7:29 PM Justin Pryzby wrote:
>
> On Thu, Dec 27, 2018 at 08:20:23PM -0500, Jeff Janes wrote:
> > Also, you would want to use the newest version of PostgreSQL, as 9.6
> > doesn't have parallel query, which is much more generally applicable than
> > effective_io_concurrency i
On Wed, Jan 9, 2019 at 3:52 PM Haroldo Kerry wrote:
> @Justin @Merlin @ Jeff,
> Thanks so much for your time and insights, they improved our understanding
> of the underpinnings of PostgreSQL and allowed us to deal the issues we
> were facing.
> Using parallel query on our PG 9.6 improved a lot
On Thu, Jan 31, 2019 at 7:30 AM Bob Jolliffe wrote:
>
> Hi Peter
>
> I did check out using ICU and the performance does indeed seem
> comparable with C locale:
>
> EXPLAIN ANALYZE select * from chart order by name COLLATE "lo-x-icu";
> QUERY PLAN
On Mon, Feb 18, 2019 at 9:49 AM Bob Jolliffe wrote:
>
> Sorry Merlin for not replying earlier. The difference is indeed hard
> to understand but it is certainly there. We altered the collation to
> use on the name field in that table and the problem has gone. Having
> having solved the immediat
On Thu, Mar 28, 2019 at 5:44 PM Raj Gandhi wrote:
>
> + pgsql-performance
>
> On Thu, Mar 28, 2019 at 6:41 PM Raj Gandhi wrote:
>>
>> Hi everyone,
>>
>>
>>
>> I’m using LIMIT offset with DB view. Looks like query planner is applying
>> the LIMIT for DB view at the end after processing all rows.
On Mon, Jul 22, 2019 at 1:42 AM Fabio Pardi wrote:
>
> Hello,
>
>
> I recently spent a bit of time benchmarking effective_io_concurrency on
> Postgres.
>
> I would like to share my findings with you:
>
> https://portavita.github.io/2019-07-19-PostgreSQL_effective_io_concurrency_benchmarked/
>
> C
On Sun, Aug 18, 2019 at 1:57 AM Mariel Cherkassky
wrote:
>
> 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_stat_statements
> 2.run the applicat
On Mon, Sep 9, 2019 at 3:55 AM yash mehta wrote:
>
> We have a query that takes 1min to execute in postgres 10.6 and the same
> executes in 4 sec in Oracle database. The query is doing 'select distinct'.
> If I add a 'group by' clause, performance in postgres improves significantly
> and fetche
On Wed, Sep 11, 2019 at 12:57 PM Rick Otten wrote:
>
> On Wed, Sep 11, 2019 at 12:38 PM Dinesh Somani wrote:
>>
>> I think Merlin has outlined pretty much all the options and very neatly. (As
>> an asides Merlin could you possibly elaborate on the "C Hack" how that might
>> be accomplished.)
>>
On Sun, Apr 14, 2019 at 3:51 PM Gunther wrote:
>
> For weeks now, I am banging my head at an "out of memory" situation. There is
> only one query I am running on an 8 GB system, whatever I try, I get knocked
> out on this out of memory. It is extremely impenetrable to understand and fix
> this
On Tue, Oct 8, 2019 at 12:44 PM Merlin Moncure wrote:
> On Sun, Apr 14, 2019 at 3:51 PM Gunther wrote:
> >
> > For weeks now, I am banging my head at an "out of memory" situation. There
> > is only one query I am running on an 8 GB system, whatever I try, I get
On Wed, Dec 18, 2019 at 3:53 AM James(王旭) wrote:
>
> Hello,
>>
>> I encountered into this kernel message, and I cannot login into the Linux
>> system anymore:
>>
>>
>>
>>> Dec 17 23:01:50 hq-pg kernel: sh (6563): drop_caches: 1
>>>
>>> Dec 17 23:02:30 hq-pg kernel: INFO: task sync:6573 blocked fo
On Tue, Feb 18, 2020 at 12:10 PM Nagaraj Raj wrote:
>
> Below are the same configurations ins .conf file before and after updagrade
>
> show max_connections; = 1743
> show shared_buffers = "4057840kB"
> show effective_cache_size = "8115688kB"
> show maintenance_work_mem = "259MB"
> show checkpoin
On Tue, Feb 18, 2020 at 12:40 PM Justin Pryzby wrote:
> This is almost certainly unrelated. It looks like that query did a seq scan
> and accessed a large number of tuples (and pages from "shared_buffers"), which
> the OS then shows as part of that processes memory, even though *shared*
> buffers
On Tue, Feb 18, 2020 at 1:10 PM Nagaraj Raj wrote:
>
> Hi Merlin,
>
> Its configured high value for max_conn, but active and idle session have
> never crossed the count 50.
>
> DB Size: 20 GB
> Table size: 30MB
> RAM: 16GB
> vC: 4
>
>
> yes, its view earlier I posted and here is there query plann
On Thu, Apr 22, 2021 at 2:55 PM Luca Ferrari wrote:
>
> On Thu, Apr 22, 2021 at 9:52 PM Bruce Momjian wrote:
> >
> > On Thu, Apr 22, 2021 at 09:45:15PM +0200, Luca Ferrari wrote:
> > > Hi all,
> > > I'm unable to find (apparently) a way to find out a possible value to
> > > start with for effecti
On Thu, Jan 20, 2022 at 4:50 PM Lugosi, Jim wrote:
>
> Hi folks,
>
>
>
> We are struggling to figure out what is going on. We are migrating from
> PostgreSQL 9.6 to PostgreSQL 13 w/ PostGIS. Our 9.6 version was compiled from
> source and the new version (13) was installed using Yum. BTW, the new
28 matches
Mail list logo
