On Wed, May 31, 2023 at 02:40:05PM +0200, Sergio Rus wrote:
> Hi guys,
>
> I've been configuring a new server and tuning Postgresql 15.3, but I'm
> struggling with a latency I'm consistently seeing with this new server when
> running fast short queries, compared to the other server.
>
> We're
On Wed, Jan 06, 2021 at 12:06:27PM -0600, Don Seiler wrote:
> On Wed, Jan 6, 2021 at 10:51 AM Joshua Drake wrote:
>
> Looking at the Azure portal metric, we are nowhere close to the advertised
> maximum IOPS or MB/s throughput (under half of the maximum IOPS and under a
> quarter of the MB/s
On Mon, Jun 22, 2020 at 03:27:32PM -0400, Alvaro Herrera wrote:
> On 2020-Jun-20, Tom Lane wrote:
>
> > I wrote:
> > > ... oh, now I see: apparently, your filter condition is such that *no*
> > > rows of the objectcustomfieldvalues table get past the filter:
> > >
> > > -> Index
On Sat, Jun 20, 2020 at 02:22:03PM -0400, Tom Lane wrote:
> I wrote:
> > ... oh, now I see: apparently, your filter condition is such that *no*
> > rows of the objectcustomfieldvalues table get past the filter:
> >
> > -> Index Scan using objectcustomfieldvalues3 on
> >
On Fri, Jun 19, 2020 at 05:25:33PM -0500, Kenneth Marshall wrote:
> On Fri, Jun 19, 2020 at 06:10:34PM -0400, Tom Lane wrote:
> > > max(objectcustomfieldvalues.objectid) = 28108423 and here is the
> > > histogram for that column:
> >
> > ... 3304313,3693956,27667
On Fri, Jun 19, 2020 at 06:10:34PM -0400, Tom Lane wrote:
> > max(objectcustomfieldvalues.objectid) = 28108423 and here is the
> > histogram for that column:
>
> ... 3304313,3693956,27667772}
>
> Hmm, does seem like you have some outlier keys. Are any of the keys in
> the column you're trying
On Fri, Jun 19, 2020 at 04:59:15PM -0400, Tom Lane wrote:
>
> > Thank you for the information and suggestion. I tried bumping the
> > statistics for the
> > objectcustomfieldvalues.objectid column to 2k, 5k and 10k followed by an
> > analyze and
> > the query plan stayed the same. I also
On Fri, Jun 19, 2020 at 04:11:10PM -0400, Tom Lane wrote:
>
> It looks like the planner is being too optimistic about how quickly the
> mergejoin will end:
>
> > -> Merge Join (cost=0.71..892.64 rows=1 width=137) (actual
> > time=21165.453..21165.453 rows=0 loops=1)
> >
Hi PostgreSQL users,
I was looking at a slow query in our CMDB that using postgresql-12.3 as its
backend. I since I am using the pg_trgm extension elsewhere I decided to give
it a try. To my surprise, the query plan did not change. But when I disabled
the index scan I got the much, much faster
Hi PostgreSQL community,
I have a system that was running version 9.6.17 running on a system with
48gb of memory and spinning disks front-ed by a HW RAID controller with
NVRAM cache. We moved to a new box running version 12.3 on a system with
64gb of memory and NVME SSD drives. Here are the
On Tue, Jul 23, 2019 at 01:41:53PM +, Kristian Ejvind wrote:
> Thanks Kenneth. In fact we've already partitioned the largest history* and
> trends* tables
> and that has been running fine for a year. Performance was vastly improved.
> But since you
> can't have a unique index on a
On Tue, Jul 23, 2019 at 08:07:55AM +, Kristian Ejvind wrote:
> Hi
>
> This will be a rather lengthy post, just to give the full (I hope) picture.
> We're using Zabbix for monitoring and I'm having problems
> understanding why the deletion of rows in the events table is so slow.
>
> Zabbix:
12 matches
Mail list logo
