public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 02/10] Run 011_crash_recovery.pl with wal_level=minimal
8+ messages / 5 participants
[nested] [flat]
* [PATCH 02/10] Run 011_crash_recovery.pl with wal_level=minimal
@ 2021-03-08 06:32 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 8+ messages in thread
From: Kyotaro Horiguchi @ 2021-03-08 06:32 UTC (permalink / raw)
The test doesn't need that feature and pg_current_xact_id() is better
exercised by turning off the feature.
Copied from: https://www.postgresql.org/message-id/20210308.173242.463790587797836129.horikyota.ntt%40gmail.com
---
src/test/recovery/t/011_crash_recovery.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/test/recovery/t/011_crash_recovery.pl b/src/test/recovery/t/011_crash_recovery.pl
index 10cd98f70a..690655dda2 100644
--- a/src/test/recovery/t/011_crash_recovery.pl
+++ b/src/test/recovery/t/011_crash_recovery.pl
@@ -11,7 +11,7 @@ use Config;
plan tests => 3;
my $node = get_new_node('primary');
-$node->init(allows_streaming => 1);
+$node->init();
$node->start;
my ($stdin, $stdout, $stderr) = ('', '', '');
--
2.17.0
--XsQoSWH+UP9D9v3l
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0003-Make-sure-published-XIDs-are-persistent.patch"
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
@ 2023-03-20 14:37 Tom Lane <[email protected]>
2023-03-20 17:46 ` Re: Save a few bytes in pg_attribute Tomas Vondra <[email protected]>
2023-03-20 23:44 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
0 siblings, 2 replies; 8+ messages in thread
From: Tom Lane @ 2023-03-20 14:37 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: pgsql-hackers
Peter Eisentraut <[email protected]> writes:
> After the discussion in [0] ff., I was looking around in pg_attribute
> and noticed that we could possibly save 4 bytes. We could change both
> attstattarget and attinhcount from int4 to int2, which together with
> some reordering would save 4 bytes from the fixed portion.
> attstattarget is already limited to 10000, so this wouldn't lose
> anything. For attinhcount, I don't see any documented limits. But it
> seems unlikely to me that someone would need more than 32k immediate
> inheritance parents on a column. (Maybe an overflow check would be
> useful, though, to prevent shenanigans.)
> The attached patch seems to work. Thoughts?
I agree that attinhcount could be narrowed, but I have some concern
about attstattarget. IIRC, the limit on attstattarget was once 1000
and then we raised it to 10000. Is it inconceivable that we might
want to raise it to 100000 someday?
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
@ 2023-03-20 17:46 ` Tomas Vondra <[email protected]>
2023-03-20 18:13 ` Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
1 sibling, 1 reply; 8+ messages in thread
From: Tomas Vondra @ 2023-03-20 17:46 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: pgsql-hackers
On 3/20/23 15:37, Tom Lane wrote:
> Peter Eisentraut <[email protected]> writes:
>> After the discussion in [0] ff., I was looking around in pg_attribute
>> and noticed that we could possibly save 4 bytes. We could change both
>> attstattarget and attinhcount from int4 to int2, which together with
>> some reordering would save 4 bytes from the fixed portion.
>
>> attstattarget is already limited to 10000, so this wouldn't lose
>> anything. For attinhcount, I don't see any documented limits. But it
>> seems unlikely to me that someone would need more than 32k immediate
>> inheritance parents on a column. (Maybe an overflow check would be
>> useful, though, to prevent shenanigans.)
>
>> The attached patch seems to work. Thoughts?
>
> I agree that attinhcount could be narrowed, but I have some concern
> about attstattarget. IIRC, the limit on attstattarget was once 1000
> and then we raised it to 10000. Is it inconceivable that we might
> want to raise it to 100000 someday?
>
Yeah, I don't think it'd be wise to make it harder to increase the
statistics target limit.
IMHO it'd be much better to just not store the statistics target for
attributes that have it default (which we now identify by -1), or for
system attributes (where we store 0). I'd bet vast majority of systems
will just use the default / GUC value. So if we're interested in saving
these bytes, we could just store NULL in these cases, no?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-20 17:46 ` Re: Save a few bytes in pg_attribute Tomas Vondra <[email protected]>
@ 2023-03-20 18:13 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2023-03-20 18:13 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
Tomas Vondra <[email protected]> writes:
> IMHO it'd be much better to just not store the statistics target for
> attributes that have it default (which we now identify by -1), or for
> system attributes (where we store 0). I'd bet vast majority of systems
> will just use the default / GUC value. So if we're interested in saving
> these bytes, we could just store NULL in these cases, no?
Hmm, we'd have to move it to the nullable part of the row and expend
more code to fetch it; but I don't think it's touched in many places,
so that might be a good tradeoff. Couple of notes:
* As things stand I think we have a null bitmap in every row of
pg_attribute already (surely attfdwoptions and attmissingval are never
both filled), so there's no extra cost there.
* Putting it in the variable part of the row means it wouldn't appear
in tuple descriptors, but that seems fine.
I wonder if the same is true of attinhcount. Since it's nonzero for
partitions' attributes, it might be non-null in a fairly large fraction
of pg_attribute rows in some use-cases, but it still seems like we'd not
be losing anything. It wouldn't need to be touched in any
high-performance code paths AFAICS.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
@ 2023-03-20 23:44 ` Andres Freund <[email protected]>
2023-03-20 23:51 ` Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
1 sibling, 1 reply; 8+ messages in thread
From: Andres Freund @ 2023-03-20 23:44 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
Hi,
On 2023-03-20 10:37:36 -0400, Tom Lane wrote:
> I agree that attinhcount could be narrowed, but I have some concern
> about attstattarget. IIRC, the limit on attstattarget was once 1000
> and then we raised it to 10000. Is it inconceivable that we might
> want to raise it to 100000 someday?
Hard to believe that'd happen in a minor version - and I don't think there'd
an issue with widening it again in a major version?
I doubt we'll ever go to 100k without a major redesign of stats storage/access
- the size of the stats datums would make that pretty impractical right now.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-20 23:44 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
@ 2023-03-20 23:51 ` Tom Lane <[email protected]>
2023-03-21 16:36 ` Re: Save a few bytes in pg_attribute Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2023-03-20 23:51 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
Andres Freund <[email protected]> writes:
> On 2023-03-20 10:37:36 -0400, Tom Lane wrote:
>> I agree that attinhcount could be narrowed, but I have some concern
>> about attstattarget. IIRC, the limit on attstattarget was once 1000
>> and then we raised it to 10000. Is it inconceivable that we might
>> want to raise it to 100000 someday?
> Hard to believe that'd happen in a minor version - and I don't think there'd
> an issue with widening it again in a major version?
True. However, I think Tomas' idea of making these columns nullable
is even better than narrowing them.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-20 23:44 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
2023-03-20 23:51 ` Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
@ 2023-03-21 16:36 ` Peter Eisentraut <[email protected]>
2023-03-21 16:43 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
0 siblings, 1 reply; 8+ messages in thread
From: Peter Eisentraut @ 2023-03-21 16:36 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Andres Freund <[email protected]>; +Cc: pgsql-hackers
On 21.03.23 00:51, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
>> On 2023-03-20 10:37:36 -0400, Tom Lane wrote:
>>> I agree that attinhcount could be narrowed, but I have some concern
>>> about attstattarget. IIRC, the limit on attstattarget was once 1000
>>> and then we raised it to 10000. Is it inconceivable that we might
>>> want to raise it to 100000 someday?
>
>> Hard to believe that'd happen in a minor version - and I don't think there'd
>> an issue with widening it again in a major version?
>
> True. However, I think Tomas' idea of making these columns nullable
> is even better than narrowing them.
The context of my message was to do the proposed change for PG16 to buy
back a few bytes that are being added by another feature, and then
consider doing a larger detangling of pg_attribute and tuple descriptors
in PG17, which might well involve taking the attstattarget out of the
hot path. Making attstattarget nullable (i.e., not part of the fixed
part of pg_attribute) would require fairly significant surgery, so I
think it would be better done as part of a more comprehensive change
that would allow the same treatment for other columns as well.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Save a few bytes in pg_attribute
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-20 23:44 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
2023-03-20 23:51 ` Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-21 16:36 ` Re: Save a few bytes in pg_attribute Peter Eisentraut <[email protected]>
@ 2023-03-21 16:43 ` Andres Freund <[email protected]>
0 siblings, 0 replies; 8+ messages in thread
From: Andres Freund @ 2023-03-21 16:43 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
Hi,
On 2023-03-21 17:36:48 +0100, Peter Eisentraut wrote:
> On 21.03.23 00:51, Tom Lane wrote:
> > Andres Freund <[email protected]> writes:
> > > On 2023-03-20 10:37:36 -0400, Tom Lane wrote:
> > > > I agree that attinhcount could be narrowed, but I have some concern
> > > > about attstattarget. IIRC, the limit on attstattarget was once 1000
> > > > and then we raised it to 10000. Is it inconceivable that we might
> > > > want to raise it to 100000 someday?
> >
> > > Hard to believe that'd happen in a minor version - and I don't think there'd
> > > an issue with widening it again in a major version?
> >
> > True. However, I think Tomas' idea of making these columns nullable
> > is even better than narrowing them.
Why not do both?
> The context of my message was to do the proposed change for PG16 to buy back
> a few bytes that are being added by another feature
How much would you need to buy back to "reach parity"?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2023-03-21 16:43 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-08 06:32 [PATCH 02/10] Run 011_crash_recovery.pl with wal_level=minimal Kyotaro Horiguchi <[email protected]>
2023-03-20 14:37 Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-20 17:46 ` Re: Save a few bytes in pg_attribute Tomas Vondra <[email protected]>
2023-03-20 18:13 ` Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-20 23:44 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
2023-03-20 23:51 ` Re: Save a few bytes in pg_attribute Tom Lane <[email protected]>
2023-03-21 16:36 ` Re: Save a few bytes in pg_attribute Peter Eisentraut <[email protected]>
2023-03-21 16:43 ` Re: Save a few bytes in pg_attribute Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox