On Fri, 12 Apr 2019 at 01:06, Etsuro Fujita wrote:
> While working on an update-tuple-routing bug in postgres_fdw [1], I
> noticed this change to ExecCleanupTupleRouting() made by commit
> 3f2393edefa5ef2b6970a5a2fa2c7e9c55cc10cf:
Added to open items list.
--
David Rowley
Hi,
I am not able to access the mailing list archive. Is the mailing list
server down or something?
--
Cheers
Ram 4.0
On Fri, Apr 12, 2019 at 1:26 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-04-11 17:04, Jeevan Chalke wrote:
> > The error is coming from get_collation_isdeterministic() when colloid
> > passed is 0. I think like we do in get_collation_name(), we should
> > return false
Hi
Is there reason why following code should not to work?
do $$
declare r record; result int;
begin
select 10 as a, 20 as b into r;
raise notice 'a: %', r.a;
execute 'select $1.a + $1.b' into result using r;
raise notice '%', result;
end;
$$
but it fails
NOTICE: a: 10
ERROR: could
On 2019-Apr-15, David Rowley wrote:
> To be honest, if I'd done a better job of thinking through the
> implications of this tablespace inheritance in ca4103025d, then I'd
> probably have not bothered submitting a patch for it. We could easily
> revert that, but we'd still be left with the same
On Fri, Apr 12, 2019 at 11:38:52PM +0900, Tatsuo Ishii wrote:
> If we were ok to add a new column to pg_stat_activity view or
> pg_stat_replication view as well, that will be great.
Okay, no objections with a separate, new, column if that's the
consensus.
--
Michael
signature.asc
Description:
On Wed, Apr 10, 2019 at 8:32 PM Andres Freund wrote:
> On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote:
> > Your explanation of existing limitations looks very good and
> > convincing. But I think there is one you didn't mention. We require
> > new table AMs to basically save old
On Tue, Apr 9, 2019 at 7:16 PM Tomas Vondra
wrote:
>
> On Sun, Apr 07, 2019 at 03:03:58AM +0300, Alexander Korotkov wrote:
> >On Sun, Apr 7, 2019 at 2:37 AM Tom Lane wrote:
> >> Alexander Korotkov writes:
> >> > Thus, contents of unused function makes test fail or pass. So far, it
> >> > looks
On Mon, Apr 15, 2019 at 10:15 AM Masahiko Sawada wrote:
>
> On Sun, Apr 14, 2019 at 4:51 AM Tomas Vondra
> wrote:
> >
> > On Thu, Apr 11, 2019 at 11:25:29AM +0200, Chris Travers wrote:
> > > On Wed, Apr 10, 2019 at 5:21 PM Andres Freund
> > > wrote:
> > >
> > > Hi,
> > >
> > > On
On Sun, Apr 14, 2019 at 4:51 AM Tomas Vondra
wrote:
>
> On Thu, Apr 11, 2019 at 11:25:29AM +0200, Chris Travers wrote:
> > On Wed, Apr 10, 2019 at 5:21 PM Andres Freund wrote:
> >
> > Hi,
> >
> > On April 10, 2019 8:13:06 AM PDT, Alvaro Herrera
> > wrote:
> > >On 2019-Mar-31,
On Mon, Apr 15, 2019 at 12:47 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Wed, Apr 3, 2019 at 10:32 PM Masahiko Sawada
> > wrote:
> >> Attached the updated version patch.
>
> > Committed with a little bit of documentation tweaking.
>
> topminnow just failed an assertion from this patch:
On Mon, 15 Apr 2019 at 05:32, Alvaro Herrera wrote:
>
> On 2019-Apr-14, Andres Freund wrote:
>
> > On 2019-04-14 10:38:05 -0400, Tom Lane wrote:
> > > It's entirely possible BTW that this whole business of inheriting
> > > tablespace from the partitioned table is broken and should be thrown
> > >
On Mon, 15 Apr 2019 at 07:19, Floris Van Nee wrote:
> 3) What could be causing the big performance difference between case 7
> (simple SELECT) and 8 (simple SELECT with ORDER BY LIMIT 1)? For 4096
> partitions, TPS of 7) is around 5, while adding the ORDER BY LIMIT 1
> makes TPS drop well
Jesper Pedersen writes:
> Yeah, that works here - apart from an issue with the test case; fixed in
> the attached.
Couple issues spotted in an eyeball review of that:
* There is code that supposes that partsupfunc[] is the last
field of ColumnsHashData, eg
fcinfo->flinfo->fn_extra
On Wed, Apr 10, 2019 at 2:52 PM Bruce Momjian wrote:
>
> OK, let me step back. Why are people resetting the statistics
> regularly? Based on that purpose, does it make sense to clear the
> stats that effect autovacuum?
>
When I've done it (not regularly, thankfully), it was usually because I
Robert Haas writes:
> On Fri, Mar 15, 2019 at 3:45 PM Tom Lane wrote:
>> I agree that copying data isn't great. What I don't agree is that this
>> solution is better.
> I am not very convinced that it makes sense to lump something like
> RelationGetIndexAttrBitmap in with something like
>
I wrote:
> Identity columns don't work if they own more than one sequence.
>
[...]
> test=> INSERT INTO ser (id) VALUES (DEFAULT);
> ERROR: more than one owned sequence found
>
>
> I propose that we check if there already is a dependent sequence
> before adding an identity column.
>
> The
Amit Langote writes:
> On 2019/04/10 15:42, Michael Paquier wrote:
>> It seems to me that Tom's argument to push in the way relcache
>> information is handled by copying its contents sounds sensible to me.
>> That's not perfect, but it is consistent with what exists (note
>> PublicationActions
On 2019-Apr-14, Andres Freund wrote:
> On 2019-04-14 10:38:05 -0400, Tom Lane wrote:
> > It's entirely possible BTW that this whole business of inheriting
> > tablespace from the partitioned table is broken and should be thrown
> > out. I certainly don't see any compelling reason for partitions
On Sun, Apr 14, 2019 at 09:11:52AM -0500, Joe Conway wrote:
On 4/13/19 3:42 PM, Tomas Vondra wrote:
If only we had a way to regularly snapshot the data from within the
database, and then compute the deltas on that. If only we could insert
data from one table into another one a then do some
On Sun, Apr 14, 2019 at 09:45:10AM -0700, Andres Freund wrote:
Hi,
On 2019-04-14 18:36:18 +0200, Tomas Vondra wrote:
I think those comparisons are cute and we did a fair amount of them when
considering a drop-in replacement for pglz, but ultimately it might be a
bit pointless because:
(a) it
On Sat, Apr 13, 2019 at 8:46 PM Robert Treat wrote:
>
> On Fri, Apr 12, 2019 at 8:18 AM Magnus Hagander
> wrote:
> > On Sun, Apr 7, 2019 at 6:28 PM Julien Rouhaud
> wrote:
> >> Thanks for looking it it!
> >> On Sun, Apr 7, 2019 at 4:36 PM Magnus Hagander
> wrote:
> >> >
> >> > I'm not sure I
On Mon, Apr 08, 2019 at 05:27:05PM -0700, Ashwin Agrawal wrote:
Heikki and I have been hacking recently for few weeks to implement
in-core columnar storage for PostgreSQL. Here's the design and initial
implementation of Zedstore, compressed in-core columnar storage (table
access method).
Hi,
On 2019-04-14 18:36:18 +0200, Tomas Vondra wrote:
> I think those comparisons are cute and we did a fair amount of them when
> considering a drop-in replacement for pglz, but ultimately it might be a
> bit pointless because:
>
> (a) it very much depends on the dataset (one algorithm may work
On Thu, Apr 11, 2019 at 06:20:47PM +0300, Heikki Linnakangas wrote:
On 11/04/2019 17:54, Tom Lane wrote:
Ashwin Agrawal writes:
Thank you for trying it out. Yes, noticed for certain patterns pg_lzcompress()
actually requires much larger output buffers. Like for one 86 len source it
required
On Thu, Apr 11, 2019 at 04:52:33PM +0300, Konstantin Knizhnik wrote:
On 11.04.2019 16:18, Andreas Karlsson wrote:
On 4/11/19 10:46 AM, Konstantin Knizhnik wrote:
This my results of compressing pbench data using different
compressors:
On Tue, Apr 09, 2019 at 02:03:09PM -0700, Ashwin Agrawal wrote:
On Tue, Apr 9, 2019 at 9:13 AM Konstantin Knizhnik
wrote:
On 09.04.2019 18:51, Alvaro Herrera wrote:
> On 2019-Apr-09, Konstantin Knizhnik wrote:
>
>> On 09.04.2019 3:27, Ashwin Agrawal wrote:
>>> Heikki
On Tue, Apr 09, 2019 at 02:29:09PM -0400, Robert Haas wrote:
On Tue, Apr 9, 2019 at 11:51 AM Alvaro Herrera wrote:
This is not surprising, considering that columnar store is precisely the
reason for starting the work on table AMs.
We should certainly look into integrating some sort of
Hi,
On 2019-04-14 10:38:05 -0400, Tom Lane wrote:
> It's entirely possible BTW that this whole business of inheriting
> tablespace from the partitioned table is broken and should be thrown
> out. I certainly don't see any compelling reason for partitions to
> act differently from regular tables
Identity columns don't work if they own more than one sequence.
So if one tries to convert a "serial" column to an identity column,
the following can happen:
test=> CREATE TABLE ser(id serial);
CREATE TABLE
test=> ALTER TABLE ser ALTER id ADD GENERATED ALWAYS AS IDENTITY;
ERROR: column "id" of
Robert Haas writes:
> On Wed, Apr 3, 2019 at 10:32 PM Masahiko Sawada wrote:
>> Attached the updated version patch.
> Committed with a little bit of documentation tweaking.
topminnow just failed an assertion from this patch:
David Rowley writes:
> On Mon, 15 Apr 2019 at 02:16, Tom Lane wrote:
>> Well, it's not really nice perhaps, but you cannot just put in some
>> other concrete tablespace OID instead. What a zero there means is
>> "use the database's default tablespace", and the point of it is that
>> it still
On Mon, 15 Apr 2019 at 02:16, Tom Lane wrote:
>
> David Rowley writes:
> > I'd say the fact that we populate reltablespace with 0 is a bug as
> > it's not going to do what they want after a dump/restore.
>
> Well, it's not really nice perhaps, but you cannot just put in some
> other concrete
David Rowley writes:
> I'd say the fact that we populate reltablespace with 0 is a bug as
> it's not going to do what they want after a dump/restore.
Well, it's not really nice perhaps, but you cannot just put in some
other concrete tablespace OID instead. What a zero there means is
"use the
On 4/13/19 3:42 PM, Tomas Vondra wrote:
> If only we had a way to regularly snapshot the data from within the
> database, and then compute the deltas on that. If only we could insert
> data from one table into another one a then do some analysics on it,
> with like small windows moving over the
>
>
> >I don't think it's helpful to force emergency vacuuming more
> >frequently;
> >quite the contrary, it's likely to cause even more issues. We should
> >tweak autovacuum to perform freezing more preemtively instead.
>
> I still think the fundamental issue with making vacuum less painful is
>
On Wed, Apr 10, 2019 at 6:13 PM Alvaro Herrera
wrote:
> On 2019-Mar-31, Darafei "Komяpa" Praliaskouski wrote:
>
> > Alternative point of "if your database is super large and actively
> written,
> > you may want to set autovacuum_freeze_max_age to even smaller values so
> > that autovacuum load
On Sat, 13 Apr 2019 at 11:36, Alvaro Herrera wrote:
> Here's a patch to fix the reported problems. It's somewhat invasive,
> and I've spent a long time staring at it, so I very much appreciate eyes
> on it.
I think it's a bit strange that don't store the pg_default's oid in
reltablespace for
Hi,
Both tables in $subject (in datatype.sgml and xfunc.sgml, respectively)
contain similar information (though the xfunc one mentions C structs and
header files, and the datatype one does not, but has a description column)
and seem similarly out-of-date with respect to the currently supported
39 matches
Mail list logo
