Hi,
JIT slot_compile_deform assumes there's at least 'natts' in TupleDesc, eg
/*
* Iterate over each attribute that needs to be deformed, build code to
* deform it.
*/
for (attnum = 0; attnum < natts; attnum++)
{
Form_pg_attribute
Hi Andres,
I have added you here as some of these are related to commits done by
you. So need your opinion on the same. I have mentioned where your
feedback will be helpful.
On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin wrote:
>
> 6. ExecGetResultSlot - remove (not used since introduction i
On Sat, Jun 01, 2019 at 12:55:47AM -0400, Alvaro Herrera wrote:
> Ah, now I remember that I tried this before, but it requires some extra
> packages installed in the machine I think, and those create running
> services. Did you note that src/backend/libpq does not even list the
> gssapi file?
Do
On Mon, Jun 3, 2019 at 6:24 PM Andres Freund wrote:
> Hi,
>
> On 2019-06-03 18:21:56 -0700, Ashwin Agrawal wrote:
> > On Mon, Jun 3, 2019 at 5:26 PM Andres Freund wrote:
> >
> > > Hi,
> > >
> > > Thanks for these!
> > >
> > > On 2019-06-03 17:24:15 -0700, Ashwin Agrawal wrote:
> > > > /*
>
On Mon, Jun 03, 2019 at 01:37:22AM -0400, Tom Lane wrote:
> It's hard to muster much enthusiasm for extending print_expr(),
> considering how incomplete and little-used it is. I'd rather
> spend effort on ripping it out in favor of using the far more
> complete, and better-tested, code in ruleutil
On Mon, Jun 03, 2019 at 04:53:48PM -0700, Ashwin Agrawal wrote:
> Please check if the attached patch addresses and satisfies all the points
> discussed so far in this thread.
It looks to be so, please see below for some comments.
> +{
> result = ReindexRelationConcurrently(heapOid, o
Hi,
On 2019-06-03 18:21:56 -0700, Ashwin Agrawal wrote:
> On Mon, Jun 3, 2019 at 5:26 PM Andres Freund wrote:
>
> > Hi,
> >
> > Thanks for these!
> >
> > On 2019-06-03 17:24:15 -0700, Ashwin Agrawal wrote:
> > > /*
> > >* Estimate the size of shared memory needed for a parallel sca
On Mon, Jun 3, 2019 at 5:26 PM Andres Freund wrote:
> Hi,
>
> Thanks for these!
>
> On 2019-06-03 17:24:15 -0700, Ashwin Agrawal wrote:
> > /*
> >* Estimate the size of shared memory needed for a parallel scan
> of this
> > - * relation. The snapshot does not need to be account
On Mon, Jun 03, 2019 at 10:49:54AM -0400, Dave Cramer wrote:
> Is there a reason why pgoutput sends data in text format? Seems to
> me that sending data in binary would provide a considerable
> performance improvement.
Are you seeing something that suggests that the text output is taking
a lot of
On Sat, Jun 01, 2019 at 12:43:11PM -0700, Andres Freund wrote:
> I don't mind at all (although it's imo not a fix for the s/heap/table)!
Thanks, committed what I had.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jun 03, 2019 at 07:33:35PM -0400, Tom Lane wrote:
> David Fetter writes:
> > It might be worth documenting the fact that NOT MATERIALIZED doesn't
> > affect DML CTEs, just as it doesn't affect statements with volatile
> > functions and recursive CTEs.
>
> We already do:
>
> However,
Hi,
Thanks for these!
On 2019-06-03 17:24:15 -0700, Ashwin Agrawal wrote:
> /*
>* Estimate the size of shared memory needed for a parallel scan of this
> - * relation. The snapshot does not need to be accounted for.
> + * relation.
>*/
> Size(*par
On Mon, Jun 3, 2019 at 10:56 PM Tom Lane wrote:
>
> Amit Langote writes:
> > On 2019/05/30 18:51, Amit Kapila wrote:
> >> I think it will be better to include postgres_fdw in the comment in
> >> some way so that if someone wants a concrete example, there is
> >> something to refer to.
>
> > Maybe
There were few more minor typos I had collected for table am, passing them
along here.
Some of the required callback functions are missing Assert checking (minor
thing), adding them in separate patch.
From f32bdf5d0d3af5fd6ee6bf6430905f9c4bf5fefa Mon Sep 17 00:00:00 2001
From: Ashwin Agrawal
Date
On Mon, Jun 03, 2019 at 11:37:30PM +0300, Konstantin Knizhnik wrote:
> but without success because ERROR_DELETE_PENDING is never returned by Win32.
> And moreover, stat() doesn't ever return error in this case.
Could it be possible to find a reliable way to detect that?
Cloberring errno with an in
On Tue, May 28, 2019 at 12:05 PM David Rowley
wrote:
> On Tue, 28 May 2019 at 01:23, Ashwin Agrawal wrote:
> > I think we will need to separate out the NOTICE message for concurrent
> and regular case.
> >
> > For example this doesn't sound correct
> > WARNING: cannot reindex exclusion constrai
David Fetter writes:
> It might be worth documenting the fact that NOT MATERIALIZED doesn't
> affect DML CTEs, just as it doesn't affect statements with volatile
> functions and recursive CTEs.
We already do:
However, if a WITH query is non-recursive and side-effect-free (that
is, it is
On Mon, Jun 03, 2019 at 11:45:51AM -0400, Elvis Pranskevichus wrote:
> Currently, WITH a AS NOT MATERIALIZED (INSERT ...) would silently
> disregard the "NOT MATERIALIZED" instruction and execute the data-
> modifying CTE to completion (as per the long-standing DML CTE rule).
>
> This seems like
Jared Rulison writes:
> Hello, we have some confusion over the planner's use of an index.
> ...
> 1. How is postgres able to use parades_city_id_description_tsv_index in the
> first explain result without any filter on "city_id"?
GIN indexes don't have any particular bias towards earlier or later
On Mon, Jun 3, 2019 at 2:59 PM Chapman Flack wrote:
> 1. (This one seems like a bug.) In the little-endian case, if
>SIZEOF_DATUM is smaller than the type, I'm not convinced by doing
>the DatumBigEndianToNative() after the memcpy(). Seems like that's
>too late to make sure the most-sig
On 6/3/19 5:59 PM, Chapman Flack wrote:
> On 6/3/19 5:03 PM, Chapman Flack wrote:
> 1. (This one seems like a bug.) In the little-endian case, if
>SIZEOF_DATUM is smaller than the type, I'm not convinced by doing
>the DatumBigEndianToNative() after the memcpy(). Seems like that's
>too l
On 6/3/19 5:03 PM, Chapman Flack wrote:
> On 6/3/19 3:23 PM, Melanie Plageman wrote:
>> Peter and I implemented this small (attached) patch to extend
>> abbreviated key compare sort to macaddr8 datatype (currently supported
>> for macaddr).
>
> Am I going cross-eyed, or would the memset be serving
Hello, we have some confusion over the planner's use of an index.
Suppose we have a table "parades" with columns:
"city_id" of type integer
"description" of type text
"start_time" of type timestamp without time zone
Suppose also we have indexes:
"parades_city_id_description_tsv_
On Mon, Jun 3, 2019 at 2:03 PM Chapman Flack wrote:
> Am I going cross-eyed, or would the memset be serving more of a purpose
> if it were in the SIZEOF_DATUM != 8 branch?
No, it wouldn't -- that's the correct place for it with the macaddr
type. However, it isn't actually necessary to memset() at
Discovered while looking into issue here:
https://github.com/citusdata/citus/pull/2733
For completeness I'll quote the example code to demonstrate the issue:
postgres=# create table events_table (id integer primary key, user_id integer);
CREATE TABLE postgres=# create table users_table_ref (id
On Mon, Jun 3, 2019 at 1:17 PM Melanie Plageman
wrote:
> I tried checking to see if there is a performance difference using the
> attached DDL based on src/test/regress/sql/macaddr8.sql. I found
> that the sort function is only exercised when creating an index (not,
> for example, when doing some
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, May 28, 2019 at 12:15:35PM -0400, Magnus Hagander wrote:
> > On Fri, May 24, 2019 at 11:24 AM Noah Misch wrote:
> > > On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > > > On Thu, May 23, 2019, 18:54 Peter Eisentraut
On Sun, May 19, 2019 at 4:07 PM Thomas Munro wrote:
> On Sat, May 18, 2019 at 12:15 PM Melanie Plageman
> wrote:
> > On Thu, May 16, 2019 at 3:22 PM Thomas Munro
> wrote:
> >> Admittedly I don't have a patch, just a bunch of handwaving. One
> >> reason I haven't attempted to write it is becaus
On 6/3/19 3:23 PM, Melanie Plageman wrote:
> Peter and I implemented this small (attached) patch to extend
> abbreviated key compare sort to macaddr8 datatype (currently supported
> for macaddr).
Am I going cross-eyed, or would the memset be serving more of a purpose
if it were in the SIZEOF_DATUM
On 03.06.2019 22:15, Robert Haas wrote:
On Thu, May 30, 2019 at 3:25 AM Konstantin Knizhnik
wrote:
If call of stat() is succeed, then my assumption is that the only reason
of GetFileAttributesEx
failure is that file is deleted and returning ENOENT error code in this
case is correct behavior.
> On Sat, Jun 1, 2019 at 6:57 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Jun 1, 2019 at 5:34 PM Floris Van Nee
> > wrote:
> >
> > I did a little bit of investigation and it seems to occur because in
> > pathkeys.c the function pathkey_is_redundant considers pathkeys redundant i
Mat Arye writes:
> On Fri, May 24, 2019 at 5:05 PM Mat Arye wrote:
>> 11.3 included some change to partition table planning. Namely
>> commit 925f46f ("Fix handling of targetlist SRFs when scan/join relation is
>> known empty.") seems to redo all paths for partitioned tables
>> in apply_scanjoin_
After many years of trying, it seems the -fsanitize=undefined checking
in gcc is now working somewhat reliably. Attached is a patch that fixes
all errors of the kind
runtime error: null pointer passed as argument N, which is declared to
never be null
Most of the cases are calls to memcpy(), memc
PG Bug reporting form writes:
> We have enabled auto_explain and see errors on PostgreSQL 11.3 when
> SELECTing from a user defined function. No such crashes have been
> observed on 10.7.
I think that you didn't give a complete dump of relevant settings,
but after some fooling around I was able t
On Thu, May 30, 2019 at 3:25 AM Konstantin Knizhnik
wrote:
> If call of stat() is succeed, then my assumption is that the only reason
> of GetFileAttributesEx
> failure is that file is deleted and returning ENOENT error code in this
> case is correct behavior.
In my experience, the assumption "th
Hi Rafia,
On 6/1/19 6:03 AM, Rafia Sabih wrote:
Here is my repeatable test case,
create table t (market text, feedcode text, updated_at timestamptz,
value float8) ;
create index on t (market, feedcode, updated_at desc);
insert into t values('TEST', 'abcdef', (select timestamp '2019-01-10
20:00:
Hi Floris,
On 6/1/19 12:10 AM, Floris Van Nee wrote:
Given a table definition of (market text, feedcode text, updated_at
timestamptz, value float8) and an index on (market, feedcode, updated_at desc)
(note that this table slightly deviates from what I described in my previous
mail) and fillin
On Monday, June 3, 2019 1:03:44 P.M. EDT Tom Lane wrote:
> CASE is a scalar-expression construct. It's got little to do with
> the timing of scan/join operations such as row fetches. We offer
> users essentially no control over when those happen ... other than
> the guarantees about CTE materiali
Amit Langote writes:
> On 2019/05/30 18:51, Amit Kapila wrote:
>> I think it will be better to include postgres_fdw in the comment in
>> some way so that if someone wants a concrete example, there is
>> something to refer to.
> Maybe a good idea, but this will be the first time to mention postgre
Elvis Pranskevichus writes:
> On Monday, June 3, 2019 12:09:46 P.M. EDT Tom Lane wrote:
>>> I understand why the rule exists in the first place, but I think
>>> that an explicit opt-in signals the assumption of responsibility
>>> and opens the possibility of using this in a well-defined
>>> evalua
On Monday, June 3, 2019 12:09:46 P.M. EDT Tom Lane wrote:
> > I understand why the rule exists in the first place, but I think
> > that an explicit opt-in signals the assumption of responsibility
> > and opens the possibility of using this in a well-defined
> > evaluation context, such as CASE WHEN
Elvis Pranskevichus writes:
> On Monday, June 3, 2019 11:50:15 A.M. EDT Andres Freund wrote:
>>> This seems like an omission to me. Ideally, the presence of an
>>> explicit "NOT MATERIALIZED" clause on a data-modifying CTE should
>>> disable the "run to completion" logic.
>> I don't see us ever
On Fri, May 31, 2019 at 2:59 AM Antonin Houska wrote:
> > Sounds good. I'm not quite sure how this is going to work. Ideally
> > you'd like the encryption key command to fetch the key from something
> > like ssh-agent, or maybe pop up a window on the user's terminal with a
> > key prompt. Just
On Monday, June 3, 2019 11:50:15 A.M. EDT Andres Freund wrote:
> > This seems like an omission to me. Ideally, the presence of an
> > explicit "NOT MATERIALIZED" clause on a data-modifying CTE should
> > disable the "run to completion" logic.
>
> I don't see us ever doing that. The result of mino
Hi,
On Saturday, we had a nice in-person conversation about the
requirements that zedstore has for an undo facility vs. the
requirements that zheap has vs. the current design of the undo patch
set. The people present were: Heikki Linnakangas, Amit Kapila, Thomas
Munro, Kuntal Ghosh, Andres Freund,
Hi,
On 2019-06-03 11:45:51 -0400, Elvis Pranskevichus wrote:
> Currently, WITH a AS NOT MATERIALIZED (INSERT ...) would silently
> disregard the "NOT MATERIALIZED" instruction and execute the data-
> modifying CTE to completion (as per the long-standing DML CTE rule).
>
> This seems like an omis
Currently, WITH a AS NOT MATERIALIZED (INSERT ...) would silently
disregard the "NOT MATERIALIZED" instruction and execute the data-
modifying CTE to completion (as per the long-standing DML CTE rule).
This seems like an omission to me. Ideally, the presence of an explicit
"NOT MATERIALIZED" cl
Heikki Linnakangas writes:
> On 29/05/2019 18:47, Hamlin, Garick L wrote:
>> On Wed, May 29, 2019 at 11:01:05AM -0400, Tom Lane wrote:
>>> At the same time, I'm not sure if we should just write this off as an
>>> ignorable warning. If the C compiler concludes these are dead stores
>>> it'll proba
Is there a reason why pgoutput sends data in text format? Seems to me that
sending data in binary would provide a considerable performance improvement.
Dave Cramer
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes:
> Thanks a lot RhodiumToad on IRC for suggestion of setting HASHES, MERGES on
> OPERATOR =.
> Now we have other problem: how do we set these flags on upgrade to new
> version of extension? Dropping an OPERATOR = will drop all indexes an v
On Sun, Jun 2, 2019 at 5:18 PM Tomas Vondra
wrote:
> Thanks for the rebase! I think the patch is in pretty good shape - I'm
> sure we'll find ways to make it more efficient etc. but IMO that's fine
> and should not prevent getting it committed.
Thank you for the in-depth review!
> Currently, the
Hi,
Thanks a lot RhodiumToad on IRC for suggestion of setting HASHES, MERGES on
OPERATOR =.
Now we have other problem: how do we set these flags on upgrade to new
version of extension? Dropping an OPERATOR = will drop all indexes an views
depending on it so isn't really an option.
Also, if someo
52 matches
Mail list logo