t here can be moved to after the isnull
check:
+ /* combine successive hash values by rotating */
+ existing_hash = pg_rotate_left32(existing_hash, 1);
--
Best regards,
Tels
Hello Tom,
On 2020-11-18 16:49, Tom Lane wrote:
Tels writes:
On 2020-11-18 06:06, Michael Paquier wrote:
On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote:
Agreed, I'm not trying to block this patch. Just wishing
there were a better way.
To me the code looks like a
for "data-driven"
refactoring.
It should be redone as generic code that reads a table of rules with
params and then checks and applies each. Thus the repetitive code would
be replaced by a bit more generic code and a lot of code-free data.
--
Best regards,
Tels
#x27;::interval, thetime)
and it would be easier, and (hopefully) faster?
Best regards,
Tels
Dear Dean,
On 2020-03-01 20:47, Dean Rasheed wrote:
On Fri, 28 Feb 2020 at 08:15, Dean Rasheed
wrote:
It's possible that there are further gains to be had in the sqrt()
algorithm on platforms that support 128-bit integers, but I haven't
had a chance to investigate that yet.
Rebased patch a
Moin,
On 2020-02-07 15:42, Emre Hasegeli wrote:
> The patch looks unduly invasive to me, but I think that it might be
> right that we should go back to a macro-based implementation, because
> otherwise we don't have a good way to be certain that the function
> parameter won't get evaluated first
will making an extension later much easier and avoids the "we need to
add X, but that breaks compatibility with all software out there"
situations that often arise a few years down the line.
Best regards,
and a happy New Year 2020
Tels
On 2019-11-24 15:38, David Steele wrote:
On 11/23/19 4:34 PM, Andrew Dunstan wrote:
On 11/23/19 3:13 AM, Tels wrote:
Without the strong hashes it would be pointless to sign the manifest.
I guess I must have missed where we are planning to add a
cryptographic
signature.
I don't
Moin,
On 2019-11-22 23:30, David Steele wrote:
On 11/22/19 5:15 PM, Tels wrote:
On 2019-11-22 20:01, Robert Haas wrote:
On Fri, Nov 22, 2019 at 1:10 PM David Steele
wrote:
> Phrased more positively, if you want a cryptographic hash
> at all, you should probably use one that isn&#x
205189.87k 361345.79k 543883.26k
638372.52k 645933.74k
Or in other words, it can hash nearly 931 MByte /s with SHA-1 and about
427 MByte / s with SHA-256 (if I haven't miscalculated something). You'd
need a
pretty fast disk (aka M.2 SSD) and network (aka > 1 Gbit) to top these
speeds
and then you'd use a real CPU for your server, not some poor Intel
powersaving
surfing thingy-majingy :)
Best regards,
Tels
The first instance would be incompressible, the
second one would be just a copy. This might not happens that often in
practical inputs, though.
I wonder if you agree and what would happen if you try this variant on
your corpus tests.
Best regards,
Tels
Moin,
On 2019-10-20 16:27, Tom Lane wrote:
Tels writes:
On 2019-10-20 13:30, Andreas Karlsson wrote:
Agreed, this sounds like something useful to do since virtually all
strict functions cannot return NULL, especially the ones which are
used in tight loops. The main design issue seems to be
t way you could do
CREATE FUNCTION f1 ... STRICT;
CREATE FUNCTION f2 ... STRICT NONULL;
CREATE FUNCTION f3 ... NONULL;
and the last wold throw "not implementet yet"? "NEVER RETURNS NULL"
would also ryme with the existing "RETURNS NULL ON NULL INPUT", but I
find the verbosity too high.
Best regards,
Tels
--
Best regards,
Tels
ple with a lot of free time on their hands will sit around,
drink a nice cup of tea and come up
with all sorts of attacks on these things that you didn't (and couldn't)
anticipate now.
So IMHO it would be much better to err on the side of caution and
encrypt everything possible.
Best regards,
Tels
= *a;
- *a-- = swap;
+ memcpy(pos - 2, DIGIT_TABLE + c, 2);
+ i += 2;
}
+ else
+ *a = (char) ('0' + value2);
+
+ return olength;
}
The line "i += 2;" modifies i, but i is never used again nor returned.
Best regards,
Tels
m,
That way it is easily changable and quite readable.
Oh, one more question. Shouldn't these regexps that start with "^" also
end with "$"? Or can there be output like:
'COMMENT ON DATABASE postgres IS $QR_IDENTIFIER; SELECT 1;'
?
Best regards,
Tels
riting the entire
JIT model.
Also, why does PG allow the stats to be that outdated - or missing, I'm
not sure which case it is in this example. Shouldn't the system aim to
have at least some basic stats, even if the user never runs ANALYZE? Or is
this on purpose for these tests to see what happens?
Best regards,
Tels
e).
Anyway, in a few places we have functions that use a lot (> a dozend)
regexps that are also moderate complex (e.g. span multiple lines). In
these cases the performance was not really up to par, so I experimented
and in the end rewrote the functions in plperl. Which fixed the
performance, so we no longer had this issue.
All the best,
Tels
Moin,
On Sat, July 21, 2018 12:47 pm, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
>> "Tels" writes:
>>> + *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
>>
>>> Shouldn't ${PGDATA} in the above as argument t
x27;m also concerned that that would let anybody who could alter the
environment then let arbitrary code be run as user postgres. Is this
something that poses a risk in addition to the current situation?
Best regards,
Tels
xed tests were
> completed, because this old machine is slow.
+ *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
Shouldn't ${PGDATA} in the above as argument to find be quoted, otherwise
the shell would get confused if it contains spaces or other special
characters?
Regards,
Tels
O
it could be "-iname" so we catch "test.PM", too?).
Also, "-print" does not handle filenames with newlines well, so "-print0"
should be used, however, this can be tricky when the next step isn't xarg,
but sort. Looking at the man page, on my system this would be:
find . -type f -name '*.p[lm]' -print0 | sort -u -z | xargs -0 ...
Not sure if that is more, or less, portable then the original -print
variant, tho.
Best regards,
Tels
d see all other (still existing) versions, if they want.
If that page is "more confusing" than a directory listing where you have
to pick the right file, or not, is of course debatable.
Regards,
Tels
x27;ve already got a problem, no?
So my favourite would be something along these lines:
* add the string_agg
* document it in the release notes, and document workaround/solutions (add
ORDER BY, disabled workers etc.)
* if not already done, stress in the documentation that if you don't OR
errors for errors. Both can be set
either to
+a comma-separated list of checks, "none" or
+"all".
quotes here around '"all"'. I think it should be one or the other in both
cases.
Also:
+ Currently
+the list of available checks includes only one:
but then it lists more than one check?
Best wishes,
Tels
ot; has its grammar at odds with
the purpose the code seems to be.
It could be named "SkipTuples" (e.g. this is the number of tuples we need
to skip, not the number we have skipped), and the other one then
"iss_SkipTuplesRemaining" so they are consistent with each other.
Others might have a better name for these two, of course.
Best wishes,
Tels
tic notifications about patches that
need rebasing, or upcoming deadlines like starting commit fests?
In addition, clear rules and well-formulated project goals would help a lot.
Also, the discussion about "needs of the project" vs. the "needs of the
users" [0] should be separat
ed by a dependent write.
+*/
(" Pairs ..." vs. ". We only ...")
Best regards,
Tels
ed git? An
account? Where? And how does it all work?
I guess a lot of potential translators who aren't programmers would be
left baffled, too.
Best regards,
Tels
mean exactly the scenario as in the attached test
case, but this works in plpgsql, too, and would be a shame to lose.
OTOH, one could also write:
SELECT INTO ba, bb a,b FROM foo(1);
and it would still work, or wouldn't it?
Best regards,
Tels
test.psql
Description: Binary data
test.pl
Description: Perl program
?
Are the uninitialized bytes that are written out "whatever was in the
memory previously" or just some "0x00 bytes from the allocation but not
yet overwritten from the PG code"?
Because the first sounds like it could be a security problem - if random
junk bytes go out to the disk, and stay there, information could
inadvertedly leak to permanent storage.
Best regards,
Tels
OMMENTS.
+ INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING
CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING STATISTICS
INCLUDING COMMENTS.
Best wishes,
Tels
Moin,
On Mon, January 15, 2018 2:34 pm, Tels wrote:
> Maybe that's a Linux-specific thing, but I always use Ctrl-D to exit a
> console, and this works with psql, too, even when in the middle of a query
> typed.
>
> So maybe this could be suggested?
Sorry, should have re
that's a Linux-specific thing, but I always use Ctrl-D to exit a
console, and this works with psql, too, even when in the middle of a query
typed.
So maybe this could be suggested?
Best wishes,
Tels
ps://blog.pgaddict.com/posts/postgresql-on-ssd-4kb-or-8kB-pages
Me thinks the next steps would be that more benchmarks are done on more
distinct hardware to see what benefits we can see, and weight this against
the complexity the patch introduces into the code base.
Hope that does make sense,
Tels
[0]: Tomas, great blog, btw!
Hello Alvaro,
On Thu, January 4, 2018 7:35 am, Alvaro Herrera wrote:
> Pavan Deolasee wrote:
>> On Tue, Jan 2, 2018 at 7:15 PM, Tels
>> wrote:
>>
>> > Just a question trying to understand how btree indexes work:
>> >
>> > If one inserts ever-in
/* if bounded, how many
tuples are needed */
If I'm not wrong, the layout of the struct will include quite a bit of
padding on 64 bit due to the mixing of bool and int64, maybe it would be
better to sort the fields differently, e.g. pack 4 or 8 bools together?
Not sure if that makes much of a difference, though.
That's all for now :)
Thank you for your work,
Tels
igh) number of levels, or does it increase in
height every insert and creates a "tall stack"?
@Peter: Could you please share your back-of-the-envelope calculation, I'd
love to get some insights into the innards.
All the best,
Tels
t; (1 row)
>
> regression=# select time '23:59:59.999';
>time
> --
> 24:00:00
> (1 row)
>
> If we didn't allow '24:00:00' as a valid value then we'd need to
> throw an error for '23:59:59.999', which doesn't seem nice.
Hm, but shouldn't the result then be "00:00:00" instead of "24:00:00"?
With addition it seems to work different:
postgres=# select time '23:59:59.99' + interval '0.01 seconds';
?column?
--
00:00:00
(1 row)
Best regards,
Tels
00:00 one day
later", that could work, but you can't just have it meaning "add 24 hours
to the clock".
For instance, during daylight saving time changes, days can be 23 hours or
25 hours long...
Best wishes,
Tels
et, so you might as well use
the CPAN version directly.
The best course seems to me to have dependencies on the OS packackes for
the Perl modules you want to use. Not sure, however, if the build farm
client has "proper" Debian etc. packages and if it is even possible to add
these dependencies in this way.
Best wishes,
Tels
Moin,
On Thu, December 28, 2017 5:43 pm, Tom Lane wrote:
> "Tels" writes:
>> On Wed, December 27, 2017 3:38 pm, Tom Lane wrote:
>>> Also, I changed PLpgSQL_var.isconst and PLpgSQL_var.notnull from "int"
>>> to "bool", which is what they
ings still worth it?
And maybe folding all four bool fields into an "int flags" field with bits
would save space, and not much slower (depending on often how the
different flags are accessed due to the ANDing and ORing ops)?
Best regards,
Tels#include
#include
#include
/*
* #in
777 - is this what is wanted here?
* none of the mkdir, chdir etc. calls check any error code, e.g. what
happens if one of them fails?
* different indentation between rmdir and move (tab vs. spaces):
+rmdir($data_path);
+ move("$backup_path", "$self->{_basedir}/pgdata")
Best regards,
Tels
Moin,
On Tue, December 26, 2017 5:26 am, Masahiko Sawada wrote:
> On Tue, Dec 26, 2017 at 6:19 PM, Tels
> wrote:
>> Moin,
>>
>> On Mon, December 25, 2017 7:26 pm, Masahiko Sawada wrote:
>>> On Tue, Dec 26, 2017 at 1:10 AM, Petr Jelinek
>>> wrote:
>
correct, just a grammar fix:
+/*
+ * If we've sent a record is at or beyond the flushed
point, then
+ * we're caught up.
That should read more like this:
"If we've sent a record that is at or beyond the flushed point, we have
caught up."
All the best,
Tels
"rand" or die; foreach (1..130) {$x="";
next if rand()> 0.; sysseek $fh,$_*8*1024,0 or die $!; sysread $fh,
$x,8*1024; print length $x} ' | uniq -c
432810 8192
real0m26,575s
user0m0,540s
sys 0m2,200s
So it does get slower, but only about 2.5 times respectively about 30%.
Hope this helps,
Tels
min_sort_mem_blocks)
+ sort_mem_blocks / (parallel_workers + (leaderasworker
? 1 : 0)) < min_sort_mem_blocks)
Thank you for working on this patch!
All the best,
Tels
48 matches
Mail list logo
