On Wed, 20 Feb 2019 at 21:35, Merlin Moncure wrote:
>
> 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
&
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
Thank you Andrew and Thomas. All is now clear :-)
On Tue, 29 Jan 2019 at 13:07, Andrew Gierth wrote:
>
> >>>>> "Bob" == Bob Jolliffe writes:
>
> Bob> Excuse me if this is a silly question. I am trying to fiddle with
> Bob> shared_buffers set
ot; would probably be no worse re sort order.
But will know better soon.
This has been a long but very fruitful investigation. Thank you all for input.
Regards
Bob
On Tue, 29 Jan 2019 at 18:47, Tom Lane wrote:
>
> Bob Jolliffe writes:
> > I wonder what can cause such a massive discr
is issue is
significant - 1000x slower on these basic sorts is crippling the
application, probably also in a number of other queries.
Regards
Bob
On Wed, 30 Jan 2019 at 23:54, Peter Geoghegan wrote:
>
> On Wed, Jan 30, 2019 at 3:57 AM Bob Jolliffe wrote:
> > (i) whether the sort o
Excuse me if this is a silly question. I am trying to fiddle with
shared_buffers setting on postgresql 10.6 on ubuntu 18.04 server.
I have this at bottom of my config file:
shared_buffers = 1GB
Yet when I check the setting from pg_setting I see something quite different:
postgres=# SELECT
Hi
We are trying to diagnose why postgres might be making poor decisions
regarding query plans. One theory is that it does not assume it has
the memory suggested in effective_cache_size.
We do know that max_connections is set quite high (600) when we don't
really expect more than 100. I wonder
Thanks Tom. Will check that.
On Tue, 17 Sep 2019 at 14:13, Tom Lane wrote:
>
> Bob Jolliffe writes:
> > We do know that max_connections is set quite high (600) when we don't
> > really expect more than 100. I wonder does the planner take
> > max_connections x wo
No brtfs. We are going to try turning off synchronous_commit
temporarily to see if there are underlying I/O issues.
On Mon, 24 May 2021 at 22:59, Alexey M Boltenkov wrote:
>
> On 05/24/21 19:24, Christophe Pettus wrote:
> >
> >> On May 24, 2021, at 09:22
wrote:
>
> I think there have been similar issues reported earlier as well. But it would
> be too early to generalize.
>
>
> Where is the db server running? Cloud?
>
> Also what is the version ?
>
>
> On Mon, May 24, 2021, 5:00 PM Bob Jolliffe wrote:
>>
>&
I am seeing a strange issue on a database using jdbc. Regularly, 4 or
5 times a day, I see something like a "stutter", where a bundle of
maybe 30 transactions suddenly finish at the same time. It looks like
(it is quite hard to catch this exactly) that the lead transaction
which has been
n some slowness.
>
> But otherwise also, do you query system, disk metrics.
>
> Do you see any anomaly in disk io (wait) when you saw blocking?
> If it did, did the io return to normal when blocks were cleared ?
>
>
>
> On Mon, May 24, 2021, 7:23 PM Bob Jolliffe wrote:
>&
Was just about to reply similarly. Mind you it perhaps does raise the
question : are the default postgresql settings perhaps too
conservative or too static. For example, in the absence of other
explicit configuration, might it make more sense for many use cases
for postgres to assess the
Hello
We have an application (https://dhis2.org) which has been using postgresql
as a backend for the past 15 years or so. Gradually moving through pg
versions 8,9,10 etc as the years went by. At the moment a large number of
our implementations are using versions 13, 14 and 15. Unfortunately
Wow Michael you are absolutely right. Turning jit off results in a query
execution about twice as fast as pg11. That is a huge relief. I will read
the jit related docs and see if there is anything smarter I should be doing
other than disabling jit entirely, but it works a treat for this query.
15 matches
Mail list logo
