resql.org/message-id/28621.1509750807%40sss.pgh.pa.us
(shortened: http://bit.ly/2zetO5T)
Seems the email-obfuskation breaks such links?
Here is a short-link for people reading it via the archive on http:
http://bit.ly/2hF4lIt
Best regards,
Tels
--
Sent via pgsql-hackers mailin
Hello David,
On Tue, October 31, 2017 7:54 pm, David G. Johnston wrote:
> On Tue, Oct 31, 2017 at 4:31 PM, Tels
> wrote:
>
>>
>>
>> That looks odd to me, it first uses output_tuples in a formula, then
>> overwrites the value with a new value. Should these lin
utput_tuples *
...
That looks odd to me, it first uses output_tuples in a formula, then
overwrites the value with a new value. Should these lines be swapped?
Best regards,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, July 30, 2017 4:35 pm, Tom Lane wrote:
> "Tels" writes:
>> On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
>>> Yeah, I looked into that. The closest candidate I can find is that
>>> perl 5.10.1 contains Test::More 0.92. However, it's not real cl
Moin,
On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
> "Tels" writes:
>> On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
>>>> So the question is, does anyone care? I wouldn't except that our
>>>> documentation appears to claim that we work w
st::More versions ready-to-use in this.
My apologies if you knew that already.
However, I do so happen to have a large archive with Perl releases and
CPAN modules. It was first mirrored on mid-2015 - so anything that was
deleted before 2015 unfortunately I can't help you with that.
But if you ne
ea why or how and it
will break with the next update to MyBase's code. While technically you
can work around that by "peeking" into MyBase's code and maybe some
reblessing, the point is that you shouldn't do nor need to do this.
Please SEE: http://perldoc.perl.org/perlobj.html
Regards,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d if it appears before
A or C.
The admin would see on the monitoring that B is offline (briefly or
permanent) and need to correct it.
>From the user's perspective, the second variant is smooth, the first is
breaking randomly. A "database user" would not really want to know that B
if I understand it correctly, #3 only works reliable in certain
cases (e.g. host down), but not if it is "sort of down". In that case each
app would again need code to retry different hosts until it finds a
working one, instead of letting libpq do the work.
That sound hard to deploy #3
On Tue, April 25, 2017 1:21 pm, Bruce Momjian wrote:
> On Tue, Apr 25, 2017 at 01:06:05PM -0400, Tels wrote:
>> Moin,
>>
>> On Mon, April 24, 2017 9:31 pm, Bruce Momjian wrote:
>> > I have committed the first draft of the Postgres 10 release notes.
>> They
>
ZE and not displayed in other cases. The new EXPLAIN option SUMMARY
allows explicit control of this feature."
Regards,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Moin,
On Fri, April 21, 2017 7:04 am, David Rowley wrote:
> On 21 April 2017 at 22:30, Tels wrote:
>> I'd rather see:
>>
>> CREATE STATISTICS stats_name ON table(col);
>>
>> as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It
>>
o be extended to both more columns, expressions or other tables
like so:
CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b);
and even:
CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b) WITH (options)
WHERE t2.a > 4;
This looks easy to remember, since it compares to:
CREATE INDEX idx_name ON t2(a,b) WITH (options) WHERE t2.a > 4;
Or am I'm missing something?
Regards,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
do it the other way round:
CREATE INDEX idx ON table (col_a);
AND:
CREATE TABLE t (
id INT REFERENCES table_2 (col_b);
);
Won't this be confusing and make things hard to remember?
Sorry for not asking earlier, I somehow missed this.
Regard,
Tels
--
Sent via pgsql-ha
Moin,
On Sat, March 11, 2017 11:29 pm, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 6:01 AM, Tels
> wrote:
>> Just a question for me to understand the implementation details vs. the
>> strategy:
>>
>> Have you considered how the scheduling decision might impact per
case you would have 5 plans running in a quasy-sequential
manner, which might be slower than the other way. Or not, that probably
needs some benchmarks?
Likewise, if you have a mix of plans with max workers like:
Plan A: 1 worker
Plan B: 2 workers
Plan C: 3 workers
Plan D: 1 worker
Plan
re should be firewall rules preventing access, but
misconfigurations, or simple changes can happen and go unnoticed. If later
the postmaster bind address changes, maybe due to an update or human
error, you got the stars aligned just right for an unauthorized access.
OTOH, that the "logical re
e is waiting for being called.
Maybe to mirror the comment on "rs_done":
/* have we started yet? */
Also, maybe it's easier for the comment to describe what is happening in
the code because of the flag, not just to the flag itself:
/* To do things once when we are called */
Anyway, it is a minor point and don't let me distract you from your work,
I do like the feature and the patch :)
Best wishes,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Aleksander,
noticed this in your patch:
> * Add a corespinding entry to pgStatTabHash.
"corresponding"
Also a question: Some one-line comments are
/* Comment. */
while others are
/*
* Comment.
*/
Why the difference?
Hope this helps,
Tels
PS: Sorry if this app
Hi Aleksander,
noticed this in your patch:
> * Add a corespinding entry to pgStatTabHash.
"corresponding"
Also a question: Some one-line comments are
/* Comment. */
while others are
/*
* Comment.
*/
Why the difference?
Hope this helps,
Tels
--
Sent via pgsql-hackers
* Does any range from range_box extend to the left side of the query? */
Also:
/* Can any range from range_box to be higher than this argument? */
should be:
/* Can any range from range_box be higher than this argument? */
Another question: Does it make sense to add the "minimal bad example fo
uot;." at the end, like these:
>+ * Also, pass down the required number of tuples
>+ * Pass down the number of required tuples by the upper node
And this comment might be better "were we already called?"
>+ boolrs_started;
22 matches
Mail list logo
