Unfortunately this two statements are not equivalent: second one can (in
theory, but not for this particular data set) return more than 10 result
records.
Such optimization will be correct if t2.i is declared as unique.
But the most efficient plan for this query will be generated if there is in
Hackers,
I've just found a little bug: extracting "epoch" from the last 30
years before Postgres' "+Infinity" leads an integer overflow:
postgres=# SELECT x::timestamptz, extract(epoch FROM x::timestamptz)
postgres-# FROM
postgres-# (VALUES
postgres(# ('294247-01-10 04:00:54.775805'),
postgres(
On 1/30/16, Pavel Stehule wrote:
>> P.S.: Have you thought to wrap the call "numeric_in" by a
>> PG_TRY/PG_CATCH instead of checking for correctness by yourself?
>
> I though about it, but it is not possible. Every PG_TRY/CATCH must be
> finished by RETHROW.
No, src/include/utils/elog.h tells dif
On Sat, Jan 30, 2016 at 3:05 AM, Merlin Moncure wrote:
> Probably want to run for at least 5 minutes via -T 300
Last time i run for 5 minutes and taken median of three runs, just missed
mentioning "-T 300" in the mail..
By looking at the results with scale factor 1000 and 100 i don't see any
r
Hi
> P.S.: Have you thought to wrap the call "numeric_in" by a
> PG_TRY/PG_CATCH instead of checking for correctness by yourself?
>
I though about it, but it is not possible. Every PG_TRY/CATCH must be
finished by RETHROW. Only when you will open subtransaction and you are
playing with resource
Hello,Pavel!
On 1/26/16, Pavel Stehule wrote:
> I am grateful for review - now this patch is better, and I hope near final
> stage.
>
> Regards
> Pavel
I'm pretty sure we are close to it.
Now besides a code design I mentioned[1] before (and no one has
answered me about it), there are a few smal
On Thu, Jan 28, 2016 at 10:10 PM, Masahiko Sawada wrote:
> By the discussions so far, I'm planning to have several replication
> methods such as 'quorum', 'complex' in the feature, and the each
> replication method specifies the syntax of s_s_names.
> It means that s_s_names could have the number o
On Thu, Jan 28, 2016 at 9:16 AM, Amit Kapila
wrote:
>
> On Thu, Jan 28, 2016 at 2:12 AM, Robert Haas
wrote:
> >
> > On Tue, Jan 26, 2016 at 3:10 AM, and...@anarazel.de
wrote:
> > > I do think there's a considerable benefit in improving the
> > > instrumentation here, but his strikes me as making
When autovacuum is off, the statistics in pg_stat_sys_tables for shared
catalogs (e.g., pg_authid, pg_database) never update. So seq_scan
doesn't update when you read the table, last_analyze doesn't update when
you run analyze, etc.
But when you shut down the server and restart it with autovacuum
On Sun, Jan 31, 2016 at 5:32 AM, Craig Ringer wrote:
> On 29 January 2016 at 22:41, Stephen Frost wrote:
>>
>> Michael,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> > On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost
>> > wrote:
>> > > * Robert Haas (robertmh...@gmail.com) wrote:
>
2016-01-30 22:38 GMT+01:00 Peter Eisentraut :
> On 1/29/16 4:15 PM, Pavel Stehule wrote:
> > Hi
> >
> > >
> > >
> > > You sent only rebased code of previous version. I didn't find
> additional
> > > checks.
> >
> > Oops. Here is the actual new code.
> >
> >
> > New test is wor
On 1/29/16 4:15 PM, Pavel Stehule wrote:
> Hi
>
> >
> >
> > You sent only rebased code of previous version. I didn't find additional
> > checks.
>
> Oops. Here is the actual new code.
>
>
> New test is working as expected
>
> I did lot of tests - and this code works perfec
On 1/28/16 10:08 AM, Alvaro Herrera wrote:
> I wonder if instead of HAVE_SYSTEMD at each callsite we shouldn't
> instead have a pg_sd_notify() call that's a no-op when not systemd.
We do this for other optional features as well, and I think it keeps the
code clearest, especially if the ifdef'ed se
On 1/28/16 9:46 AM, Christoph Berg wrote:
> If a cluster is configured for non-hot-standby replication, the
> READY=1 seems to never happen. Did you check if that doesn't trigger
> any timeouts with would make the unit "fail" or the like?
As Pavel showed, it doesn't work for that. I'll look into
On Sat, Jan 30, 2016 at 2:13 PM, Noah Misch wrote:
> You could offer that paragraph as an objection to almost all Assert(), elog(),
> and automated tests. Why levy it against this patch? The valuable ways
> assertions and tests supplement review are well-established.
Sure, that's true, but I do
On 29 January 2016 at 18:16, Andres Freund wrote:
> Hi,
>
> so, I'm reviewing the output of:
>
Thankyou very much for the review.
> > + pglogical_output_plhooks \
>
> I'm doubtful we want these plhooks. You aren't allowed to access normal
> (non user catalog) tables in output plugi
On 29 January 2016 at 22:41, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost
> wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
> > >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> > wrote:
On 30 January 2016 at 05:11, Robert Haas wrote:
>
> Well, this gets at one of the problems here, which is that you can't
> fix a commit message once the commit has been pushed. So even if we
> all agreed in principle to a standard format, it's not clear that you
> could enforce compliance with th
On Sat, Jan 30, 2016 at 07:37:45AM -0500, Robert Haas wrote:
> On Fri, Jan 29, 2016 at 11:19 PM, Noah Misch wrote:
> > As you say, forbidding things makes friction in the event that someone comes
> > along wanting to do the forbidden thing. Forbidding things also simplifies
> > the system, making
On 2016-01-21 04:17, Simon Riggs wrote:
Marko, I was/am waiting for an updated patch. Could you comment please?
Sorry, I've not found time to work on this recently.
Thanks for everyone's comments so far. I'll move this to the next CF
and try and get an updated patch done in time for that one
On Fri, Jan 29, 2016 at 3:46 AM, Ashutosh Bapat
wrote:
> PFA patch to move code to deparse SELECT statement into a function
> deparseSelectStmtForRel(). This code is duplicated in
> estimate_path_cost_size() and postgresGetForeignPlan(), so moving it into a
> function avoids that duplication. As a
On Fri, Jan 29, 2016 at 9:13 PM, Michael Paquier wrote:
> Well, to put it short, I am just trying to find a way to make the
> backend skip unnecessary checkpoints on an idle system, which results
> in the following WAL pattern if system is completely idle:
> CHECKPOINT_ONLINE
> RUNNING_XACTS
> RUNN
On Sat, Jan 30, 2016 at 2:25 AM, Peter Geoghegan wrote:
> On Fri, Jan 29, 2016 at 2:58 PM, Robert Haas wrote:
>> I don't quite know what you mean by these numbers. Add a generic,
>> conservative threshold to what?
>
> I meant use "quicksort with spillover" simply because an estimated
> 90%+ of a
On 30 January 2016 at 13:48, Robert Haas wrote:
> On Sat, Jan 30, 2016 at 7:37 AM, Petr Jelinek wrote:
>> Just as a note, CREATE SEQUENCE ACCESS METHOD already causes grammar
>> conflict now, that's why my proposal was different, I didn't want to
>> add more keywords. I think Alvaro's proposal is
On Sat, Jan 30, 2016 at 7:37 AM, Petr Jelinek wrote:
> Just as a note, CREATE SEQUENCE ACCESS METHOD already causes grammar
> conflict now, that's why my proposal was different, I didn't want to
> add more keywords. I think Alvaro's proposal is fine as well.
I missed your proposal, I guess, so pl
On Sat, Jan 30, 2016 at 5:22 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera
>> wrote:
>
>> > Personally I don't see value in having the commit message follow a
>> > machine-parseable format; like if you say "Backpatch to" instead of
>> > "Backpat
On 29 January 2016 at 23:59, Robert Haas wrote:
> On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote:
>> Alexander Korotkov writes:
>>> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera
>>> wrote:
I'm thinking we'd do CREATE ACCESS METHOD foobar TYPE INDEX or something
like that.
>>
>>> I
On Fri, Jan 29, 2016 at 11:19 PM, Noah Misch wrote:
> As you say, forbidding things makes friction in the event that someone comes
> along wanting to do the forbidden thing. Forbidding things also simplifies
> the system, making it easier to verify. This decision should depend on the
> API's aud
On Fri, Jan 29, 2016 at 11:21 PM, Fabien COELHO wrote:
> +/* overflow check (needed for INT64_MIN) */
> +if (lval != 0 && (*retval < 0 == lval < 0))
>
> Why not use "if (lval == INT64_MIN)" instead of this complicated condition?
> If it is really needed for some reason, I t
Robert Haas wrote:
> On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera
> wrote:
> > Personally I don't see value in having the commit message follow a
> > machine-parseable format; like if you say "Backpatch to" instead of
> > "Backpatch-through:" makes your commit message wrong. I think what was
On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera
wrote:
>> I think the best question to ask is:
>>
>> "What is the problem we are trying to solve?"
>
> The problem is alluring more patch reviewers, beta testers and bug
> reporters. One of the offers is to credit them (I'm not exactly clear
> on wh
On 29 January 2016 at 21:11, Alexander Korotkov
wrote:
> Hi, Petr!
>
> On Sat, Jan 23, 2016 at 1:22 AM, Petr Jelinek
> wrote:
>
>> here is updated version of this patch, calling the messages logical
>> (decoding) messages consistently everywhere and removing any connection to
>> standby messages
On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila
wrote:
> On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas
> wrote:
> >
> > On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
> > wrote:
> > > On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > > wrote:
> > >> So far as
33 matches
Mail list logo
