On Sat, Jan 19, 2019 at 01:19:46PM -0500, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Fri, Jan 18, 2019 at 4:02 PM Tom Lane wrote:
> > > Magnus Hagander writes:
> > > > On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier
> > > wrote:
> > > >> Wouldn't it be better
Hi,
On 2019-01-27 08:03:17 +0100, Greg Stark wrote:
> I assume you already considered and rejected having a fixed size null
> bitmap followed by a variable size array of datums. That seems like it
> would be denser and work better with cpu cache.
It'd be more expensive to access individually
I assume you already considered and rejected having a fixed size null
bitmap followed by a variable size array of datums. That seems like it
would be denser and work better with cpu cache.
I guess the reason you prefer the struct is because it can be used
elsewhere on its own?
On 1/26/19 9:46 PM, Tom Lane wrote:
> Andres Freund writes:
>> The buildfarm largely seems to have had no problem with it, but handfish
>> failed:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=handfish=2019-01-26%2022%3A57%3A19
>> but I have no idea what the error is, nor whether
I understand it's not fully supported to replicate to a differently
partitioned setup on a subscriber with either pglogical or the native
logical replication, however I also know that INSERT triggers can be fired
in replication mode. I have an insert-only OLTP table that I want
partitioned only
Andres Freund writes:
> The buildfarm largely seems to have had no problem with it, but handfish
> failed:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=handfish=2019-01-26%2022%3A57%3A19
> but I have no idea what the error is, nor whether it's related to this
> failure, because for
Andres Freund writes:
> On 2019-01-26 20:53:48 -0500, Tom Lane wrote:
>> I have no idea why we're seeing this in only one buildfarm member
>> and only for the past week or so, as it doesn't appear that any
>> related code has changed for months. (Perhaps something changed
>> about curculio's
Hi,
On 2019-01-25 12:51:02 -0800, Andres Freund wrote:
> Updated patch attached. Besides the above changes, there's a fair bit
> of comment changes, and I've implemented the necessary JIT changes.
I pushed a further polished version of this.
The buildfarm largely seems to have had no problem
Hi,
On 2019-01-26 20:53:48 -0500, Tom Lane wrote:
> Recently, buildfarm member curculio has started to show a semi-repeatable
> failure in src/test/recovery/t/013_crash_restart.pl:
>
> # aborting wait: program died
> # stream contents: >>psql::8: no connection to the server
> # psql::8:
Recently, buildfarm member curculio has started to show a semi-repeatable
failure in src/test/recovery/t/013_crash_restart.pl:
# aborting wait: program died
# stream contents: >>psql::8: no connection to the server
# psql::8: connection to server was lost
# <<
# pattern searched for: (?^m:server
On Sat, Jan 26, 2019 at 12:22 AM Tom Lane wrote:
> Therefore, I'm reversing my previous opinion that we should not have
> an explicit NOT MATERIALIZED option. I think we should add that, and
> the behavior ought to be:
>
> * No option given: inline if there's exactly one reference.
>
> * With
I wrote:
> Therefore, I'm reversing my previous opinion that we should not have
> an explicit NOT MATERIALIZED option. I think we should add that, and
> the behavior ought to be:
> * No option given: inline if there's exactly one reference.
> * With MATERIALIZED: never inline.
> * With NOT
Fabien COELHO writes:
>> It's unclear to me whether to push ahead with Daniel's existing
>> patch or not. It doesn't look to me like it's making things
>> any worse from the error-consistency standpoint than they were
>> already, so I'd be inclined to consider error semantics cleanup
>> as
> On Thu, Dec 20, 2018 at 2:46 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> I've performed some testing, and on my environment with a dataset of 10^7
> records:
>
> * everything below 7.5 * 10^5 unique records out of 10^7 was faster with skip
> scan.
>
> * above 7.5 * 10^5 unique records
I wrote:
> There's a considerable amount of follow-up work that ought to happen
> now to make use of these capabilities for places that have been
> pain points in the past, such as generate_series() and unnest().
> But I haven't touched that yet.
Attached is an 0004 that makes a stab at providing
> "Tom" == Tom Lane writes:
Tom> The reason that it's reappeared is the refactoring we've done
Tom> recently around snprintf: float4out is now taking its float4
Tom> argument and widening it to double to pass to strtod, which is
Tom> where the checks for Inf/NaN happen.
[...]
Tom> to
I see that opossum's owner just resurrected it after a period of being
MIA ... and it's failing a few regression tests with symptoms like
this:
SELECT 'NaN'::float4;
- float4
-
-NaN
+ float4
+--
+ Infinity
(1 row)
I have no doubt that this is caused by the same platform
Jim Finnerty writes:
> It's related, but what I was referring to applies even to the uncorrelated
> case: suppose you have something like:
> select x, sum(z)
> from t
> where
> x > 5 and y in ('a', 'b', 'c')
> group by x;
> let's say that 'a', 'b', and 'c' are not frequent values of y, so
=?UTF-8?Q?L=C3=A6titia_Avrot?= writes:
> [ adding_log10_and_hyperbolic_functions_v1.patch ]
No objection to the feature, but
- Why are you using the float4-width library functions (coshf etc)
rather than the float8-width ones (cosh etc)?
- I wonder whether these library functions exist
Michael Meskes writes:
> I wonder if it would be better to make the test cases use the proper
> whenever command instead. That would give us a slightly better
> functionality testing I'd say.
I like having a hard limit on the number of loop iterations;
that should ensure that the test terminates
On Sat, Jan 26, 2019 at 5:05 AM John Naylor wrote:
>
> On Thu, Jan 24, 2019 at 5:19 AM Amit Kapila wrote:
> >
> Performance testing is probably a good idea anyway, but I went ahead
> and implemented your next idea:
>
> > The other alternative is we can fetch pg_class.relpages and rely on
> >
On Sat, Jan 26, 2019 at 1:35 PM Nick B wrote:
> On Sat, Jan 26, 2019 at 4:23 AM Michael Paquier
> wrote:
> > These are a bit unregular. Which files are taking that long to
> > complete while others are way faster? It may be something that we
> > could improve on the base backup side as there
> It looks to me like the reason that the ecpg tests went into an
> infinite
> loop is that compat_informix/test_informix.pgc has not considered the
> possibility of repeated statement failures:
> ...
Correct, this was missing a safeguard.
> I know zip about ecpg coding practices, but wouldn't
On Sat, Jan 26, 2019 at 4:23 AM Michael Paquier wrote:
> These are a bit unregular. Which files are taking that long to
> complete while others are way faster? It may be something that we
> could improve on the base backup side as there is no actual point in
> syncing segments while the backup
On Sat, 26 Jan 2019 at 02:17, Tom Lane wrote:
> Shay Rojansky writes:
> > Thanks for insisting - I ended up setting up the environment and running
> > the tests, and discovering that some test-related changes were missing.
> > Here's a 3rd version of the patch. Hope this is now in good shape,
On 1/23/19 3:12 AM, Kuroda, Hayato wrote:
Dear Adrien,
Hello Kuroda-san
config.sgml
You must document the behavior when users change the parameter during a
transaction.
あやしい・・・
Agreed, I added a wording.
postgres.c
I give you three comments.
/* flag for
Hello hackers,
In his blog post (What's new in SQL 2016)[
https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016], Markus Winand
explained some of the changes added to SQL:2016. I spotted that Postgres
was behind other RDBMS on hyperbolic functions and log10 function.
The log10 function
On 25/01/2019 15:37, Chapman Flack wrote:
>> External links already create footnotes in the PDF output. Is that
>> different from what you are saying?
> That might, only, indicate that I was just thinking aloud in email and
> had not gone and checked in PDF output to see how the links were
On 25/01/2019 16:19, Tom Lane wrote:
> Peter Eisentraut writes:
>> committed
>
> Some of the buildfarm members are having sort-ordering problems
> with this. Looks like you could work around it with different
> partition names (don't assume the relative sort order of
> letters and digits).
>
>
>
>> My second problem with this proposal is that it simply ignores
>> the naming precedent of the existing polymorphic types. We have
>> a convention that polymorphic types are named "any-something",
>> and I do not think we should just toss that overboard. Moreover,
>> if we do end up
30 matches
Mail list logo
