iki/Integer_square_root and I think it's a
well-known result in the field.
Regards,
Dean
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
new file mode 100644
index 10229eb..9986132
--- a/src/backend/utils/adt/numeric.c
+++ b/src/backend/utils/adt/numeric.c
@@ -393,16
On Fri, 27 Mar 2020 at 11:29, Peter Eisentraut
wrote:
>
> We appear to have lost track of this.
Ah yes, indeed!
> I have re-read everything and
> expanded your patch a bit with additional documentation and comments in
> the tests.
I looked that over, and it all looks good to me.
Regards,
Dean
x27;s a minor detail.
>
OK, I've pushed that with your recommendation for that function name.
Regards,
Dean
On Sat, 28 Mar 2020 at 13:18, Dean Rasheed wrote:
>
> OK, I've pushed that with your recommendation for that function name.
>
Does this now complete everything that you wanted to do for functional
dependency stats for PG13? Re-reading the thread, I couldn't see
anything else
vacstmt=0x29b0ca8, isTopLevel=true) at vacuum.c:251
It looks to me as though the problem is that statext_store() needs to
take its lock on pg_statistic_ext_data *before* searching for the
stats tuple to update.
It's late here, so I haven't worked up a patch yet, but it looks
pretty straightforward.
Regards,
Dean
On Tue, 31 Mar 2020 at 22:16, Tom Lane wrote:
>
> > Dean Rasheed writes:
> >> ...
> >> It looks to me as though the problem is that statext_store() needs to
> >> take its lock on pg_statistic_ext_data *before* searching for the
> >> stats tuple to upd
ed patch.
While at it, I noticed an XXX code comment questioning whether any of
this applies to MERGE. The answer is "no", because MERGE actions don't
allow multi-row inserts, so I think it's worth updating that comment
to make that clearer.
Regards,
Dean
diff --git a/src/backend
.
So it actually needs to examine rd_rules. Technically, I think that it
would be sufficient to just test whether rd_rules is non-NULL, but I
think it's more robust and readable to check rd_rules->numLocks, as in
the attached patch.
Regards,
Dean
diff --git a/src/backend/parser/parse_merge
e T_Float case, causing
it to fall through to numeric_in() and fail:
SELECT -0x8000;
ERROR: invalid input syntax for type numeric: "-0x8000"
^
Regards,
Dean
right place.
Hmm, I'm not quite sure how that would work. Possibly we could
identify the VALUES RTE while building the product query, but that
looks pretty messy.
Regards,
Dean
On Wed, 23 Nov 2022 at 15:32, Tom Lane wrote:
>
> Not quite sure the added test case is worth the cycles.
>
No, probably not, for such a trivial change.
Pushed to HEAD and 15, without the test. Thanks for looking!
Regards,
Dean
at the start of the rtable. Of course that would
break if we ever changed the way rewriteRuleAction() worked, but at
least it only depends on that one other place in the code, which has
been stable for a long time, so the risk of future breakage seems
managable.
Regards,
Dean
diff --git a/src/backend/
s isn't correct, because those functions are meant to accumulate a
negative number in "tmp".
The overflow check can't just ignore the final digit either, so I'm
not sure how much this would end up saving once those issues are
fixed.
Regards,
Dean
if (unlikely(acc >= cutoff))
goto out_of_range;
acc = acc * 10 + (*ptr - '0');
ptr++;
}
and similar for other bases, allowing the coding for all bases to be
kept similar.
I think it's probably best to consider this as a follow-on patch
though. It shouldn't delay getting the main feature committed.
Regards,
Dean
a negative position to round at
> > positions to the left of the decimal point (this is undocumented though...)
> > which the actual cast cannot do, but that seems like a marginal case.
Note that, as of PG15, "n" can be negative in such typemods, if you
want to round before the decimal point.
The fact that passing a negative scale to round() isn't documented
does seem like an oversight though...
Regards,
Dean
think differently. I feel like it's a fairly trivial task to
> rebase.
>
> If the consensus is that we should fix this afterwards, then I'm happy to
> delay.
>
I feel like it should be done afterwards, so that any performance
gains can be measured for all bases. Otherwise, we won't really know,
or have any record of, how much faster this was for other bases, or be
able to go back and test that.
Regards,
Dean
ugh it's not broken now, it's morally wrong, and it
risks breaking when Peter commits his patch.
Regards,
Dean
commands supporting ONLY, and it
would be a pain to make them that.
Regards,
Dean
diff --git a/doc/src/sgml/ref/merge.sgml b/doc/src/sgml/ref/merge.sgml
new file mode 100644
index e07adda..bc7f4b4
--- a/doc/src/sgml/ref/merge.sgml
+++ b/doc/src/sgml/ref/merge.sgml
@@ -22,13 +22,13 @@ Post
On Fri, 9 Dec 2022 at 10:02, Alvaro Herrera wrote:
>
> On 2022-Dec-08, Nathan Bossart wrote:
>
> > On Thu, Dec 08, 2022 at 03:26:52PM +, Dean Rasheed wrote:
> > > While testing MERGE, I noticed that it supports inheritance
> > > hierarchies and the ONLY k
o and came to much the same conclusion,
so I think this is a safe change that makes the code a little neater
and more efficient.
Regards,
Dean
rule, so the product queries don't rely on the expanded
targetlist, and never have.
Regards,
Dean
h permute()
> already present in this script.
Yes, I think removing the test is the best option. It was originally
added because there was a separate code path for larger permutation
sizes that needed testing, but that's no longer the case so the test
really isn't adding anything.
Regards,
Dean
this 48 bit PRNG that I
> may be motivated enough to attempt to replace it, or at least add a better
> (faster?? larger state?? same/better quality?) alternative.
>
I don't necessarily have a problem with that provided the replacement
is well-chosen and has a proven track record (i.e., let's not invent
our own PRNG).
For now though, I'll go remove the test.
Regards,
Dean
e prefered option.
>
That's something for consideration in v15. If we do decide we want a
new PRNG, it should apply across the board to all pgbench random
functions.
Regards,
Dean
On Tue, 10 Jan 2023 at 14:43, Dean Rasheed wrote:
>
> Rebased version attached.
>
Rebased version, following 8eba3e3f02 and 5d29d525ff.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index b87ad5c..1482ede
--- a/doc/src/sgml/mvcc.sgml
On Mon, 9 Jan 2023 at 17:44, Dean Rasheed wrote:
>
> On Mon, 9 Jan 2023 at 16:23, Vik Fearing wrote:
> >
> > Bikeshedding here. Instead of Yet Another WITH Clause, could we perhaps
> > make a MERGING() function analogous to the GROUPING() function that goes
> > wit
_var_int() for all small divisors. So
the var2ndigits <= 2 case needs to come first.
The implementation of div_var_int64() should be in an #ifdef HAVE_INT128 block.
In div_var_int64(), s/ULONG_MAX/PG_UINT64_MAX/
Regards,
Dean
On Sun, 22 Jan 2023 at 15:41, Joel Jacobson wrote:
>
> On Sun, Jan 22, 2023, at 11:06, Dean Rasheed wrote:
> > Seems like a reasonable idea, with some pretty decent gains.
> >
> > Note, however, that for a divisor having fewer than 5 or 6 digits,
> > it's no
on_tables.pdf
>
Thanks, that's a very useful reference.
(And I do indeed have one of those CPUs, which explains what I was seeing.)
Regards,
Dean
ting, the gains look good to me, and I wasn't able
to find any cases where it made things slower, so I've gone ahead and
pushed it.
Regards,
Dean
On Mon, 23 Jan 2023 at 15:55, Peter Eisentraut
wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
&
x27;s just hope they don't decide to use
RETURNING in an incompatible way in the future.
> Regarding mas_action_idx, I would have thought that it belongs in
> MergeAction rather than MergeActionState. After all, you determine it
> once at parse time, and it is a constant from there onwards, right?
>
Oh, yes that makes sense (and removes the need for a couple of the
executor changes). Thanks for looking.
Regards,
Dean
On Wed, 4 Jan 2023 at 09:28, Dean Rasheed wrote:
>
> In addition, I think that strip_underscores() could then go away if
> numeric_in() were made to handle underscores.
>
> Essentially then, that would move all responsibility for parsing
> underscores and non-decimal intege
t of Postgres
users need it. Perhaps start a new thread to gauge people's interest?
Regards,
Dean
On Tue, 24 Jan 2023 at 00:47, Ranier Vilela wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
&g
should have a numeric
variant (for integers only, since non-integers won't necessarily
terminate in hex, aren't accepted as inputs, and don't seem
particularly useful anyway). I don't think two's complement output
makes much sense for numeric, so perhaps it should only have the
prefix option, and always output signed hex strings.
Thoughts?
Regards,
Dean
hex(abs(x))
from ( values (-2147483648) ) as s(x);
ERROR: integer out of range
Part of the reason for implementing this in core would be to save
users from such easy-to-overlook bugs.
Regards,
Dean
view comments Tomas posted. In particular, this
shouldn't need any changes to IndexStmt. I think the best approach
would be to just add a new function to backend_progress.c that offsets
a specified progress parameter by a specified amount, so that you can
just increment partitions_done by one or more, at the appropriate
points.
Regards,
Dean
e there is. This is easy to code in C using unsigned ints,
without resorting to abs() (yes, I'm aware that abs() is undefined for
INT_MIN).
Regards,
Dean
---
-2147483648
(1 row)
SELECT pg_typeof(-0x8000);
pg_typeof
---
integer
(1 row)
Regards,
Dean
On Wed, 25 Jan 2023 at 21:43, Peter Eisentraut
wrote:
>
> On 24.01.23 14:10, Dean Rasheed wrote:
> > I also think it might be useful for it to gain a couple of boolean options:
> >
> > 1). An option to output a signed value (defaulting to false, to
> > preserve the c
ted columns. That could be
improved by examining the merge action list (it would be OK to skip
generated columns as long as the MERGE didn't contain an INSERT
action), but I don't think it's worth the extra effort / risk.
So I think we need the attached in HEAD and v15.
Regards,
Dean
d
gt; In passing, also add pow10[] values for DEC_DIGITS==2 and DEC_DIGITS==1,
> since otherwise it's not possible to compile such DEC_DIGITS values
> due to the assert:
>
> StaticAssertDecl(lengthof(pow10) == DEC_DIGITS, "mismatch with
> DEC_DIGITS");
>
That might be worth doing, to ensure that the code still compiles for
other DEC_DIGITS/NBASE values. I'm not sure how useful that really is
anymore though. As the comment at the top says, it's kept mostly for
historical reasons.
Regards,
Dean
this formula is only an
approximation, since it's not using the exact input decimal weight. So
my inclination is to leave the code as-is. It does guarantee that the
result has at least 16 significant digits, which is the intention.
Regards,
Dean
rily impact their performance.
Regards,
Dean
2) * 2)
sweight = arg.weight * DEC_DIGITS / 2 + 1;
#else
if (arg.weight >= 0)
sweight = arg.weight * DEC_DIGITS / 2 + 1;
else
sweight = 1 - (1 - arg.weight * DEC_DIGITS) / 2;
#endif
Regards,
Dean
EXIT WHEN NOT FOUND;
INSERT INTO wine_audit VALUES('U', now(), oldrec, newrec);
END LOOP;
CLOSE oldcur;
CLOSE newcur;
END;
END IF;
RETURN NULL;
END;
$$;
though it would be nicer if there was a way to do it in a single SQL statement.
Regards,
Dean
On Tue, 31 Jan 2023 at 21:59, Joel Jacobson wrote:
>
> Nice, you managed to simplify it even further.
> I think the comment and the code now are crystal clear together.
>
> I've tested it successfully, test report attached.
>
Cool. Thanks for testing.
Committed.
Regards,
Dean
ing, it's either intentional, or because I forgot, so the
reminder would be useful.
And as someone who runs pgindent regularly, I think this will be a net
time saver, since I won't have to skip over other unrelated indent
changes all the time.
Regards,
Dean
On Thu, 2 Feb 2023 at 22:40, Peter Eisentraut
wrote:
>
> On 31.01.23 17:09, Dean Rasheed wrote:
> > On Tue, 31 Jan 2023 at 15:28, Peter Eisentraut
> > wrote:
> >>
> >> Did you have any thoughts about what to do with the float types? I
> >> gu
On Sat, 21 Jan 2023 at 14:18, Ted Yu wrote:
>
> On Sat, Jan 21, 2023 at 3:05 AM Dean Rasheed wrote:
>>
>> Rebased version, following 8eba3e3f02 and 5d29d525ff.
>>
Another rebased version attached.
> In transform_MERGE_to_join :
>
> +
On Mon, 23 Jan 2023 at 16:54, Dean Rasheed wrote:
>
> On Sun, 22 Jan 2023 at 19:08, Alvaro Herrera wrote:
> >
> > Regarding mas_action_idx, I would have thought that it belongs in
> > MergeAction rather than MergeActionState. After all, you determine it
> > o
might shave a few percent off some simple numeric operations, but I
doubt it will make much difference to more complex computations. I'd
need to see some more realistic test results, or some real evidence of
palloc/pfree causing significant overhead in a numeric computation.
Regards,
Dean
diff --
for a normal update), and then ExecMergeMatched() will
update it again.
I think the best fix is to have ExecMergeMatched() pass canSetTag =
false to ExecUpdateAct(), so that ExecMergeMatched() takes
responsibility for updating estate->es_processed in all cases.
Regards,
Dean
diff --git a/src/
(and hence non-empty withCheckOptionLists to
initialise).
So I think we need something like the attached.
Regards,
Dean
diff --git a/src/backend/executor/execPartition.c b/src/backend/executor/execPartition.c
new file mode 100644
index 651ad24..fd6ca8a
--- a/src/backend/executor/execPartition.c
expected, I don't think there's
much point in adding a regression test case for it though.
Regards,
Dean
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
new file mode 100644
index 7581661..651930a
--- a/doc/src/sgml/spi.sgml
+++ b/doc/src/sgml/spi.sgml
@@ -438,6 +438,15
On Mon, 20 Feb 2023 at 19:39, Tom Lane wrote:
>
> Ugh. Grepping around, it looks like pltcl_process_SPI_result
> is missing a case for SPI_OK_MERGE as well.
>
Yes, I was about to post a patch for that too. That's the last case
that I found, looking around.
Regards,
Dean
Another one noticed in the MERGE RETURNING patch -- this allows PL/Tcl
to execute MERGE (i.e., don't fail when SPI returns SPI_OK_MERGE). I'm
not sure if anyone uses PL/Tcl anymore, but it's a trivial fix,
probably not worth a regression test case.
Regards,
Dean
diff --git a/src/p
gt; need duplicative estimates. Don't have time to work on that right now
> though ... Dean, are you interested in fixing this?
>
Here's a patch along those lines, bringing power_var_int() more in
line with neighbouring functions by having it choose its own result
scale.
It was nec
On Tue, 18 Oct 2022 at 20:18, Robert Haas wrote:
>
> On Tue, Oct 18, 2022 at 6:18 AM Dean Rasheed wrote:
> > Overall, I'm quite happy with these results. The question is, should
> > this be back-patched?
> >
> > In the past, I think I've only back-patche
_MIN)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("bigint out of range")));
and FWIW it works OK on my dev box with gcc 10.2.1 and the same cflags.
Regards,
Dean
;, or some such -- as it stands it's being set to false
for an Expr Op Expr clause, which doesn't seem right because there
*is* an expression on the left.
Regards,
Dean
ype, while the final variance
could be quite small (and that can't be fixed by rounding). So this
too fails when parallel workers are used, and succeeds otherwise, and
the patch fixes this too, so I added a separate test case for it.
Regards,
Dean
diff --git a/src/backend/utils/adt/numer
e code nicely as well as saving a buffer copy.
I'm not a fan of the *serialize() function names in numeric.c though
(e.g., the name numeric_serialize() seems quite misleading for what it
actually does). So rather than adding to those, I've kept the original
names. In the context where they&
ber
because only the power_var_int() code path in power_var() handles
negative bases correctly. Attached is a patch to fix that.
Regards,
Dean
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
new file mode 100644
index eb78f0b..3eb0d90
--- a/src/backend/utils/adt/numeri
rting this.
Regards,
Dean
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
new file mode 100644
index de561cd..1777c41
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -545,7 +545,7 @@
NUMERIC(precision, scale)
- The precision must be positive, the
there's no
change to the way numeric values are stored. The only change is to
extend the allowed scale in the numeric typemod.
Regards,
Dean
nce a client could send
> us corrupt data e.g. during a binary copy. There are currently no
> external factors to account for with serial/deserial.
OK, fair enough. That makes it more compact and efficient.
I'll post an update in a while. Thanks for the review.
Regards,
Dean
On Thu, 1 Jul 2021 at 10:27, Dean Rasheed wrote:
>
> I'll post an update in a while. Thanks for the review.
>
One other thing I'm wondering about is back-patching. I was originally
thinking of these as back-patchable bug fixes, but changing the binary
format of the aggregate s
I think it's probably not worth doing this. I remain sceptical that it
could give that much of a performance gain, and keeping the
platform-independent state might well be useful in the future.
Regards,
Dean
On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
>
> Numeric x^y is supported for x < 0 if y is an integer, but this
> currently fails if y is outside the range of an int32
>
I've been doing some more testing of this, and I spotted another
problem with numeric_power().
out there on how to do it better -- see,
for example, [1] for a nice summary.
Also, I'd say that functions to choose random integers in an arbitrary
range ought to be part of the common API, as they are in almost every
language's random API.
Regards,
Dean
[1] https://www.pcg-random.org/posts/bounded-rands.html
aster depending on implementation and platform, but in the context of
the DB as a whole, I don't think a few extra cycles matters either
way. The method recommended at the very end of that blog seems to be
pretty good all round, but any of the other commonly used unbiased
methods would probably be OK too.
Regards,
Dean
atively much bigger.
>
> So likely performance isn't too critical here, but it is something to
> keep in mind.
>
Yes, agreed. I suspect there's not much more that can be shaved off
this particular piece of code now though. Here's an update with the
last set of changes discuss
On Fri, 2 Jul 2021 at 12:56, David Rowley wrote:
>
> On Fri, 2 Jul 2021 at 22:55, Dean Rasheed wrote:
> > Here's an update with the
> > last set of changes discussed.
>
> Looks good to me.
Thanks for the review and testing!
> Just the question of if we have any
ainly sufficient for any realistic use case (-1000 means numbers
are rounded to the nearest multiple of 10^1000).
Also, keeping some spare bits in the typemod might come in handy one
day for something else (e.g., rounding mode choice).
Regards,
Dean
diff --git a/doc/src/sgml/datatype.sgml b/doc/src
On Sat, 3 Jul 2021 at 08:06, Fabien COELHO wrote:
>
> Here is a v4, which:
>
> - moves the stuff to common and fully removes random/srandom (Tom)
> - includes a range generation function based on the bitmask method (Dean)
> but iterates with splitmix so that the state al
ys be returned, when starting from
that initial seed.
Regards,
Dean
really relevant now, but I'm pretty sure that's impossible to do.
You might try it as an interesting academic exercise, but I believe
it's a logical impossibility.
Regards,
Dean
t;might happen for certain invalid inputs" errors, so init_var() should
always be called in these functions.
Regards,
Dean
On Sun, 4 Jul 2021 at 09:43, David Rowley wrote:
>
> On Sat, 3 Jul 2021 at 11:04, Dean Rasheed wrote:
> > Thinking about this more, I think it's best not to risk back-patching.
> > It *might* be safe, but it's difficult to really be sure of that. The
> > bug
haps say "Otherwise, compare the MCVItem with the
constant" and "Otherwise compare the values from the MCVItem using the
clause operator", or something like that.
But other than such cosmetic things, I think the patch is good, and
gives some nice estimate improvements.
Regards,
Dean
hes that,
rightshifts will always equal unit->unitBits or unit->unitBits - 1, so
it'll never do more than one half-round, which is important.
So perhaps using doHalfRound would be clearer, but it could just be a
local variable tracking whether or not it's the first time through the
loop.
Regards,
Dean
double-round in numeric sqrt().
To be clear, I'm not saying that the current code half-rounds more
than once, just that it reads as if it does.
Regards,
Dean
een
some quite deeply nested views in practice, but never that deep).
For comparison, this is what SELECT performance looked like for me
without the patch:
| SELECT
-+--
v64 |9.589
v128 | 73.292
v256 | 826.964
v512 | 7844.419
so, for a one-line change, that's pretty impressive.
Regards,
Dean
tables 0.04 s, client-side
generate 51.81 s, vacuum 2.11 s, primary keys 19.63 s)
Nice!
Regards,
Dean
te) >> rshift;
}
while (val > range);
}
else
val = 0;
which reduces the complexity a bit.
Regards,
Dean
re wrong.
The reason is that bit shifting isn't the same as division for
negative numbers, since bit shifting rounds towards negative infinity
whereas division rounds towards zero (truncates), which is what I
think we really need.
Regards,
Dean
On Thu, 1 Jul 2021 at 14:17, Dean Rasheed wrote:
>
> On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
> >
> > Numeric x^y is supported for x < 0 if y is an integer, but this
> > currently fails if y is outside the range of an int32
>
> I've been doing so
an 'overflows numeric format':
>
> errmsg("bigint out of range")));
>
> Maybe rephrase as: value is out of range
>
Hmm, I don't know. That's the error that has been thrown by lots of
numeric functions for a long time now, and it seems fine to me.
Regards,
Dean
sion test would be ok to back-patch?
+1
Here's an update with matching updates to the numeric code, plus the
regression tests.
Regards,
Dean
diff --git a/src/backend/utils/adt/dbsize.c b/src/backend/utils/adt/dbsize.c
new file mode 100644
index 9c39e7d..d03e103
--- a/src/backend/utils/adt/d
erate_series() and pgbench's
random() function.
I think it makes more sense to do it that way, because then such
functions can work all the way up to and including the limit of the
bound's datatype, which makes them more general.
Regards,
Dean
emoving the 0 - to test positive numbers.
Wow, that's a lot of testing! I just tried a few hand-picked edge cases.
> If you like, I can push this in my morning, or if you'd rather do it
> yourself, please go ahead.
No, I didn't get as much time as I thought I would today, so please go ahead.
Regards,
Dean
_errposition() indicator helps the user identify the problem.
In file_fdw_validator(), where there is no pstate, it's already using
"specified more than once" as a hint to clarify the "conflicting or
redundant options" error, so I think we should leave that alone.
Regards,
Dean
On Sat, 10 Jul 2021 at 11:44, Dean Rasheed wrote:
>
> I'm inclined to think that it isn't worth the effort trying to
> distinguish between conflicting options, options specified more than
> once and faked-up options that weren't really specified. If we just
> make er
On Sat, 10 Jul 2021 at 18:30, Tom Lane wrote:
>
> [ moving to pghackers for wider visibility ]
>
> Dean Rasheed writes:
> > On Sat, 10 Jul 2021 at 16:01, Tom Lane wrote:
> >> In general, I'm disturbed that we just threw away the previous
> >> promise
#x27;s used in lots of small, fast functions (see, for
example, float_overflow_error()).
In general though, I think inline and noinline should be reserved for
special cases where they give a clear, measurable benefit, and that in
general it's better to not mark the function and just let the compiler
decide.
Regards,
Dean
quot; specified more than once
LINE 1: copy (select 1) to stdout csv csv header;
^
which isn't good because there is no option called "format".
Regards,
Dean
check the node type, but that could be fixed by using
lfirst_node() instead of lfirst() at the start of the loop, which
would be neater.
Regards,
Dean
break;
which wouldn't fall over if the subquery were NULL.
Regards,
Dean
301 - 400 of 654 matches
Mail list logo
