On 07/21/2014 10:47 PM, Anastasia Lubennikova wrote:
Hi, hackers!
There are new results of my work on GSoC project "Index-only scans for
GIST".
Previous post is here:
http://postgresql.1045698.n5.nabble.com/Index-only-scans-for-GIST-td5804892.html
Repository is
https://github.com/lubennikovaav/p
On 7/22/14, 7:06 AM, Pavel Stehule wrote:
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
What dependency? The patch only looks at the raw parser output, so it
won't e.g. know whether SELECT * INT
On 2014-07-22 10:09:04 +0900, MauMau wrote:
> >From: "Andres Freund"
> >>On 2014-07-18 23:38:09 +0900, MauMau wrote:
> >>>So, I propose a simple fix to change the LOG level to DEBUG1. I don't
> >>>know
> >>>which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
> >>>include this i
Please find attached 2 patches, which are a split of the patch discussed in
this thread.
Please find attached a very minor improvement to apply a code (variable
name) simplification directly in patch A so as to avoid a change in patch
B. The cumulated patch is the same as previous.
(A) ad
On Thu, 2014-07-10 at 23:43 -0700, Jeff Davis wrote:
> On Mon, 2014-07-07 at 01:21 -0700, Jeff Davis wrote:
> > On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote:
> > > On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote:
> > > > Thanks for the detailed feedback, I'm sorry it took so long to
On Tue, Jul 22, 2014 at 10:53 AM, Rajmohan C wrote:
> How do I modify PostgreSQL 9.3 source to skip certain join combinations
> (skip building certain paths in path tree) by checking some condition
>
have a look at joinpaths.c
How do I modify PostgreSQL 9.3 source to skip certain join combinations
(skip building certain paths in path tree) by checking some condition
Hi
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
This check should not be integrated to function validation directly.
We can integrate it to plpgsql_check
Regards
Pavel
2014-07-21 22:56 GMT+02:0
This patch does update the documentation as stated, and make it
consistent with the reality and the embedded psql help. This is an
improvement and I recommand its inclusion.
I would also suggest to move the sentence at the end of the description:
"\pset without any arguments displays the curre
On Tue, May 27, 2014 at 1:52 AM, Peter Geoghegan wrote:
>
> While talking to various people during pgCon, I was reminded that the
> nbtree README does a poor job of explaining the actual practical
> advantages of L&Y from a high level. The "move right" trick is
> initially mentioned only as an adj
"Jonathan S. Katz" writes:
> On Jul 21, 2014, at 9:51 PM, Tom Lane wrote:
>> The short reason why not is that it's not an operator (where "operator"
>> is defined as "something with a pg_operator entry"), and all our indexing
>> infrastructure is built around the notion that indexable clauses are
According to
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2014-07-21%2022%3A36%3A55
prairiedog saw a crash in "make check" on the 9.4 branch earlier tonight;
but there's not a lot of evidence as to why in the buildfarm report,
because the postmaster log file is truncated wel
On Jul 21, 2014, at 9:51 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an
>> indexable operation in a B-tree index,
>
> The short reason why not is that it's not an operator (where "operator"
> is defined as "something wit
On 21 July 2014 13:39, Fabien COELHO Wrote
> This patch does update the documentation as stated, and make it
> consistent with the reality and the embedded psql help. This is an
> improvement and I recommand its inclusion.
>
> I would also suggest to move the sentence at the end of the descriptio
Andrew Dunstan writes:
> On 07/21/2014 02:40 PM, Tom Lane wrote:
>> I had the same feeling about the Perl on RHEL6 ;-). The TAP tests
>> will need to be a great deal more portable than they've proven so far
>> before they'll really be useful for anything much. I trust we're
>> committed to makin
Hi Asif,
On Wed, Jul 9, 2014 at 6:51 PM, Haribabu Kommi
wrote:
> On Mon, Jul 7, 2014 at 6:59 PM, Asif Naeem wrote:
> > Hi Haribabu,
> >
> > Thank you for sharing the patch. I have spent some time to review the
> > changes. Overall patch looks good to me, make check and manual testing
seems
> > r
"Jonathan S. Katz" writes:
> I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an
> indexable operation in a B-tree index,
The short reason why not is that it's not an operator (where "operator"
is defined as "something with a pg_operator entry"), and all our indexing
infrastruct
From: "Andres Freund"
On 2014-07-18 23:38:09 +0900, MauMau wrote:
So, I propose a simple fix to change the LOG level to DEBUG1. I don't
know
which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
include this in 9.2.9?
Surely that's the wrong end to tackle this from. Hiding
On Mon, Jul 21, 2014 at 4:57 PM, Andres Freund wrote:
> I rather doubt it will. x in (y1, ... yn) is essentially expanded to x =
> y1 OR x = y2, ... OR x = yn. I.e. the NULL comparison will be done using
> normal equality comparison and thus not return a row with a NULL
> orderid. Am I missing som
On 2014-07-21 16:51:32 -0700, Peter Geoghegan wrote:
> On Mon, Jul 21, 2014 at 4:16 PM, Jonathan S. Katz
> wrote:
> > With NULLs being indexable, I was wondering if there was some reason why IS
> > NOT DISTINCT FROM could not use the index?
>
> FWIW this works:
>
> postgres=# explain analyze se
On Mon, Jul 21, 2014 at 4:16 PM, Jonathan S. Katz
wrote:
> With NULLs being indexable, I was wondering if there was some reason why IS
> NOT DISTINCT FROM could not use the index?
FWIW this works:
postgres=# explain analyze select * from orders where orderid in (5, null);
Hi,
I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an indexable
operation in a B-tree index, as it is effectively testing for equality albeit
with some "magic" for NULLs? Here is an example of what I mean, running tests
on 9.3.4:
-- create a table of integers
Hi again,
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
.marko
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 4730,4736 a_output := a_output || $$ if v_$$ || referrer_k
Alvaro Herrera writes:
> Tom Lane wrote:
>> No, ALTER SYSTEM is there now and it needs to work right in its first
>> release. I will go fix this if nobody else does.
> Just checking -- you didn't get around to dealing with this, right?
Not yet... do you want it?
regards
Tom Lane wrote:
> Josh Berkus writes:
> >> 2. *Then*, in a second pass, enforce requirements like "can't be
> >> changed except at server start".
>
> > This would also make conf.d much more useful; I wouldn't have to worry
> > as much about overlapping config settings.
>
> > Sounds like a 9.5 f
Hi, hackers!
There are new results of my work on GSoC project "Index-only scans for
GIST".
Previous post is here:
http://postgresql.1045698.n5.nabble.com/Index-only-scans-for-GIST-td5804892.html
Repository is
https://github.com/lubennikovaav/postgres/tree/indexonlygist2
Patch is in attachments.
It
On 07/21/2014 02:40 PM, Tom Lane wrote:
Robert Haas writes:
Mmph. Well, I don't want to install a non-default Perl on my system
just to make these tests pass, and I don't think that should be a
requirement.
I had the same feeling about the Perl on RHEL6 ;-). The TAP tests
will need to be a
Robert Haas writes:
> Mmph. Well, I don't want to install a non-default Perl on my system
> just to make these tests pass, and I don't think that should be a
> requirement.
I had the same feeling about the Perl on RHEL6 ;-). The TAP tests
will need to be a great deal more portable than they've
On Mon, Jul 21, 2014 at 12:00 PM, Thomas Fanghaenel
wrote:
> On Mon, Jul 21, 2014 at 8:21 AM, Robert Haas wrote:
>> The tests weren't running for me at all on MacOS X, because I was
>> missing some prerequisite. So I installed it, and now they promptly
>> fail:
>>
>> ok 2 - initdb --version
>>
Fundamental issue:
PostgreSQL is different than Oracle in how it stores BLOBs
http://www.postgresql.org/docs/9.1/static/catalog-pg-largeobject.html.
In PostgreSQL ...
In the particular tables BLOBS are stored as OID's (unique numbers).
There is one table for all BLOB data (see pg_largeobject under
On Mon, Jul 21, 2014 at 9:51 AM, Andres Freund
wrote:
>
> On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> > > The rewrite will read in the 'old' contents - but because it's done
> > > after the pg_class.relpersistence is changed they'll all not be marked
> > > as BM_PERMANENT in mem
On Mon, Jul 21, 2014 at 8:21 AM, Robert Haas wrote:
> The tests weren't running for me at all on MacOS X, because I was
> missing some prerequisite. So I installed it, and now they promptly
> fail:
>
> ok 2 - initdb --version
> 1..2
> ok 1 - initdb with invalid option nonzero exit code
>
For some reason, or possibly just through my carelessness and for no
real reason, json_object() currently disallows empty strings as object
keys. However silly empty string keys might be, they are apparently
allowed by the JSON rfcs, and this behaviour by json_object() is
inconsistent with what
On Fri, Jul 18, 2014 at 7:01 PM, Brightwell, Adam
wrote:
>> I think we do want a way to modify policies. However, we tend to
>> avoid syntax that involves unnatural word order, as this certainly
>> does. Maybe it's better to follow the example of CREATE RULE and
>> CREATE TRIGGER and do somethin
--On 12. Juli 2014 15:08:01 +0200 Magnus Hagander
wrote:
Before doing that, however, I'd like to ask for opinions :) The hack
currently exposes a separate view that you can join to
pg_stat_activity (or pg_stat_replication) on the pid -- this is sort
of the same way that pg_stat_replication
On Mon, Jul 21, 2014 at 10:06 AM, Christoph Berg wrote:
> Re: Noah Misch 2014-07-18 <20140718052625.ga2231...@tornado.leadboat.com>
>> Installing a new version of one Perl module is well within the capabilities
>> of
>> buildfarm owners. Saving them the trouble, which in turn means more of them
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > > trying to think of a way to put it under that command. What if we had a
> > > more general way to reference 'all objects in a
The first two shapes on src/test/regress/sql/polygon.sql do not make
sense to me. They look more like polygons with some more tabs,
but still did not match the coordinates. I changed them to make
consistent with the shapes. I believe this was the intention of
the original author. Patch attached
Re: Noah Misch 2014-07-18 <20140718052625.ga2231...@tornado.leadboat.com>
> Installing a new version of one Perl module is well within the capabilities of
> buildfarm owners. Saving them the trouble, which in turn means more of them
> actually activating the TAP tests, might justify the loss. I'd
On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> > The rewrite will read in the 'old' contents - but because it's done
> > after the pg_class.relpersistence is changed they'll all not be marked
> > as BM_PERMANENT in memory. Then the ALTER TABLE is rolled back,
> > including the relpe
Re: Fabrízio de Royes Mello 2014-07-16
> Anyway I think all is ok now. Is this ok for you?
Hi Fabrízio,
it's ok for me now, though Andres' concerns seem valid.
> > > +SET TABLESPACE class="PARAMETER">new_tablespace
> > > RESET ( class="PARAMETER">storage_parameter [, ... ] )
> > >
On Sun, Jul 20, 2014 at 7:44 AM, Amit Kapila wrote:
> On Fri, Jul 18, 2014 at 7:08 PM, MauMau wrote:
>>
>> From: "Magnus Hagander"
>>
>>> On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila
>>> wrote:
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
wrote:
>
>
> Did anyone
During internals tests, it is observed that checkpointer
is getting crashed on slave with below log on slave in
windows:
LOG: checkpointer process (PID 4040) was terminated by exception 0xC005
HINT: See C include file "ntstatus.h" for a description of the hexadecimal
value.
LOG: terminating
Currently \pset is supported without any argument also, so same is updated in
documentation.
\pset option [ value ]
Changed to
\pset [ option [ value ] ]
This patch does update the documentation as stated, and make it consistent
with the reality and the embedded psql help. This is an impro
On Sun, Jul 20, 2014 at 10:41 PM, Craig Ringer wrote:
> I'd be very keen to see atomic upsert in Pg. Please Cc me on any patches
> / discussion, I'll be an eager tester.
Great. Thanks Craig.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
45 matches
Mail list logo
