Are you able to cluster the table ? The idea is that rows ordered in the
same way as the index might reduce it's size ?
On Wed, 30 Oct 2024, 16:29 Don Seiler, wrote:
> On Wed, Oct 30, 2024 at 11:23 AM Peter Geoghegan wrote:
>
>>
>> If a substantial amount of the index was written by CREATE IND
On Wed, Oct 30, 2024 at 11:23 AM Peter Geoghegan wrote:
>
> If a substantial amount of the index was written by CREATE INDEX (and
> not by retail inserts) then my theory is unlikely to be correct. It
> could just be that you managed to absorb most inserts in one
> partition, but not in the other.
On Wed, Oct 30, 2024 at 12:08 PM Don Seiler wrote:
> Why would last month's index be so much smaller?
Because the split heuristics worked as designed there. That's the
theory, at least.
> Both indexes were created using CONCURRENTLY, as each was created during its
> month when we started testin
On Wed, Oct 30, 2024 at 10:45 AM Peter Geoghegan wrote:
>
> It sounds like you have no updates and deletes. Right? So the only
> thing that could be different is the way that the pages are being
> split (aside from variations in the width of index tuples, which seems
> highly unlikely to be the o
Settings, like "SELECT * FROM pg_settings;"
On Wed, Oct 30, 2024 at 11:32 AM alexander al (leiden)
wrote:
> Hi,
>
> we have a supplier (via our client) who has an self build PAAS-version
> of postgresql. Ok, you would say, that's fine. But, there is always an
> but, we think the settings are not
On Wed, Oct 30, 2024 at 11:39 AM Don Seiler wrote:
> Thanks Peter, I'll look into that shortly.
It sounds like you have no updates and deletes. Right? So the only
thing that could be different is the way that the pages are being
split (aside from variations in the width of index tuples, which see
Hi,
we have a supplier (via our client) who has an self build PAAS-version
of postgresql. Ok, you would say, that's fine. But, there is always an
but, we think the settings are not quite ok. We really want to know how
much memory etc there is on that server. So we can recommend the
recommended set
On Wed, Oct 30, 2024 at 10:35 AM Peter Geoghegan wrote:
> On Wed, Oct 30, 2024 at 11:24 AM Don Seiler wrote:
> > One thing worth mentioning is that the table is 4 columns, the index is
> on two of them and includes the other two. I can't think of an explanation
> for the index being so much larg
On Wed, Oct 30, 2024 at 11:24 AM Don Seiler wrote:
> One thing worth mentioning is that the table is 4 columns, the index is on
> two of them and includes the other two. I can't think of an explanation for
> the index being so much larger than its table, especially compared to last
> month's in
We're trying out a new non-unique covering (including) index on a couple of
table partitions. We put the index on partitions for last month and this
month. Both table partitions have similar sizes (45-46 GB) and row counts
(330-333 million). The covering index on last month's partition is 50GB,
but
>>Greg Sabino Mullane writes:
>> I'd echo the suggestion to strace this. You can use the pre_auth_delay
>> setting to help facilitate that. See:
>IIUC, the delays are rare and unpredictable, so that strace'ing seems
>unlikely to be practical.
>If rebuilding from source is feasible, you could ins
Greg Sabino Mullane writes:
> I'd echo the suggestion to strace this. You can use the pre_auth_delay
> setting to help facilitate that. See:
IIUC, the delays are rare and unpredictable, so that strace'ing seems
unlikely to be practical.
If rebuilding from source is feasible, you could insert mon
I'd echo the suggestion to strace this. You can use the pre_auth_delay
setting to help facilitate that. See:
https://www.postgresql.org/docs/current/runtime-config-developer.html
Cheers,
Greg
On Wed, 30 Oct 2024 at 13:04, Ian J Cottee wrote:
> Hello everyone, I’ve been using postgres for over 25 years now and never
> had any major issues which were not caused by my own stupidity. In the last
> 24 hours however I’ve had a number of issues on one client's server which I
> assume are a b
Hello everyone, I’ve been using postgres for over 25 years now and never
had any major issues which were not caused by my own stupidity. In the last
24 hours however I’ve had a number of issues on one client's server which I
assume are a bug in postgres or a possible hardware issue (they are runnin
>> What we've found out so far is, that this only happens if we have a
>> localhost(or any other hostname) line before the line matching our
>> connection, something like this:
>> host replication x localhost md5
>> host all x xx.xx.xx.0/24
16 matches
Mail list logo
