On Tue, Oct 1, 2013 at 7:49 AM, Bruce Momjian br...@momjian.us wrote:
On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
Shouldn't we do it for Set Constraints as well?
Oh, very good point. I missed that one. Updated patch attached.
I am glad you are seeing things I am not.
Thanks Bruce.
Yes for me main problem was to make assumption that a 5-digit number is a
year,
as was bit worried about side effect of that assumption in the date/time
module. I
did tested patch shared by you with various test and so far it looks good
to me.
I would like reviewer to review/test
Pavel Stehule pavel.steh...@gmail.com writes:
If you can do a update of some array in plpgsql now, then you have to work
with local copy only. It is a necessary precondition, and I am think it is
valid.
If the proposal only relates to assignments to elements of plpgsql local
variables, it's
2013/10/3 Tom Lane t...@sss.pgh.pa.us
Pavel Stehule pavel.steh...@gmail.com writes:
If you can do a update of some array in plpgsql now, then you have to
work
with local copy only. It is a necessary precondition, and I am think it
is
valid.
If the proposal only relates to assignments
On 03.10.2013 01:05, Kevin Grittner wrote:
Andres Freundand...@2ndquadrant.com wrote:
On 2013-10-01 07:41:46 -0700, Kevin Grittner wrote:
Andres Freundand...@2ndquadrant.com wrote:
A better solution probably is to promote tuple-level locks if
they exist to a relation level one upon
On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur samthaku...@gmail.com wrote:
Looks pretty good. Do you want to package up the patch with your
change and do the honors and re-submit it? Thanks for helping out so
much!
Sure, will do. Need to add a bit of documentation explaining
statistics
You are right, wget worked. Latest patch looks good to me. make check run
fine. Thank you Peter.
On Wed, Oct 2, 2013 at 5:02 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/2/13 5:12 AM, Asif Naeem wrote:
Neither git nor patch command apply the patch successfully. Can you
please guide
The idea is to allow configuration of standby servers such that they have
there own set of replication parameters as per requirements.
How does this interplay with the synchronous_standby_names parameter ? Or
do you think that becomes irrelevant if we do like what you are suggesting
above
On Tue, Oct 1, 2013 at 11:37 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Magnus Hagander wrote:
On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote:
Given that, I'm fine
On Wed, Oct 2, 2013 at 6:12 AM, Peter Eisentraut pete...@gmx.net wrote:
On Wed, 2013-09-25 at 14:26 +0530, Jeevan Chalke wrote:
So no issues from my side.
However, do we still need this in close_pl() ?
#ifdef NOT_USED
if (FPeq(line-A, -1.0) FPzero(line-B))
{
From: Alvaro Herrera alvhe...@2ndquadrant.com
Can you please send a fixup patch to what's already committed?
OK, I'll send a patch against HEAD, which will be a few lines. Am I
understanding the meaning of fixup patch?
Regards
MauMau
--
Sent via pgsql-hackers mailing list
Heikki Linnakangas hlinnakan...@vmware.com wrote:
IMHO it would be better to remove xmin from the lock key, and vacuum
away the old predicate locks when the corresponding tuple is vacuumed.
The xmin field is only required to handle the case that a tuple is
vacuumed, and a new unrelated tuple
MauMau escribió:
From: Alvaro Herrera alvhe...@2ndquadrant.com
Can you please send a fixup patch to what's already committed?
OK, I'll send a patch against HEAD, which will be a few lines. Am I
understanding the meaning of fixup patch?
Yep, thanks.
--
Álvaro Herrera
On Mon, Sep 30, 2013 at 5:28 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 30. September 2013 19:00:06 +0200 Andres Freund
and...@2ndquadrant.com wrote:
HEAD (default):
tps = 181738.607247 (including connections establishing)
tps = 182665.993063 (excluding connections establishing)
On 2013-10-01 00:28:55 +0200, Bernd Helmle wrote:
--On 30. September 2013 19:00:06 +0200 Andres Freund
and...@2ndquadrant.com wrote:
HEAD (default):
tps = 181738.607247 (including connections establishing)
tps = 182665.993063 (excluding connections establishing)
HEAD (padding + 16
On 09/30/2013 09:08 AM, Kevin Grittner wrote:
Steve Singer st...@ssinger.info wrote:
How about
To support matching of rows which include elements without a default
B-tree operator class, the following operators are defined for composite
type comparison:
literal*=/,
On Thu, Oct 3, 2013 at 11:54:14AM +0530, Rushabh Lathia wrote:
Thanks Bruce.
Yes for me main problem was to make assumption that a 5-digit number is a
year,
as was bit worried about side effect of that assumption in the date/time
module. I
did tested patch shared by you with various test
On Thu, Oct 3, 2013 at 11:50:09AM +0530, Amit Kapila wrote:
I looked at this but could not see how to easily pass the value of
'isTopLevel' down to the SELECT. All the other checks have isTopLevel
passed down from the utility case statement.
Yes, we cannot pass isTopLevel, but as
On Thu, Oct 3, 2013 at 09:59:03AM -0400, Steve Singer wrote:
Are there any outstanding issues on this patch preventing it from
being committed?
I have not received answers to my email of October 1:
http://www.postgresql.org/message-id/20131001024620.gb13...@momjian.us
--
Bruce
On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
Shouldn't we do it for Set Constraints as well?
Oh, very good point. I missed that one. Updated patch attached.
I am glad you are seeing things I am not. :-)
1. The
* Robert Haas (robertmh...@gmail.com) wrote:
I'm wary of inventing a completely new way of doing this. I don't
think that there's any guarantee that the send/recv functions won't
expose exactly the same implementation details as a direct check for
binary equality.
I don't follow this
Steve,
Thanks for following-up on this; I had meant to reply much sooner but
other things got in the way.
Thanks again,
Stephen
* Steve Singer (st...@ssinger.info) wrote:
Are there any outstanding issues on this patch preventing it from
being committed?
I think we
On 2013-10-01 16:11:47 -0400, Steve Singer wrote:
On 09/30/2013 06:44 PM, Andres Freund wrote:
Hi,
The series from friday was a bit too buggy - obviously I was too
tired. So here's a new one:
With this series I've also noticed
#2 0x007741a7 in ExceptionalCondition (
On Sat, Sep 28, 2013 at 8:42 AM, Marko Tiikkaja ma...@joh.to wrote:
On 2013-09-28 12:31, Ian Lawrence Barwick wrote:
The patch looks good to me now; does the status need to be changed to
Ready for Committer?
Yes.
Thanks for reviewing!
This looks like a nice clean patch. My only concern is
On 10/03/2013 12:38 PM, Andres Freund wrote:
Does your code use SELECT FOR UPDATE/SHARE on system or
treat_as_catalog tables? Greetings, Andres Freund
Yes.
It declares sl_table and sl_sequence and sl_set as catalog.
It does a
SELECT ..
from @NAMESPACE@.sl_table T, @NAMESPACE@.sl_set
On Oct 2, 2013, at 5:07 AM, Merlin Moncure mmonc...@gmail.com wrote:
Hrm. I get a seq scan for that query:
create index on try(upper_inf(irange));
explain select * from try where upper_inf(irange);
QUERY PLAN
Bruce Momjian br...@momjian.us wrote:
On Fri, Sep 27, 2013 at 03:34:20PM -0700, Kevin Grittner wrote:
We first need to document the existing record comparison operators.
If they read the docs for comparing row_constructors and expect
that to be the behavior they get when they compare records,
On Wed, Oct 2, 2013 at 7:17 PM, Jim Nasby j...@nasby.net wrote:
On 9/29/13 9:41 PM, Andrew Dunstan wrote:
On 09/29/2013 10:38 PM, Peter Eisentraut wrote:
On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
Well if these are not meant to be changed then not being able to write
them in
David,
But anyway, I still don’t understand why, if the function used to store the
value is immutable (as upper_inf() is), why Postgres doesn't do an index
scan. Is this something that could be improved in the planner?
Yes. This is clearly a TODO.
--
Josh Berkus
PostgreSQL Experts Inc.
Steve Singer st...@ssinger.info wrote:
You haven't adjusted the patch to reduce the duplication between the
equality and comparison functions, if you disagree with me and feel that
doing so would increase the code complexity and be inconsistent with how
we do things elsewhere that is fine.
I
On Thu, Oct 3, 2013 at 11:12 AM, Stephen Frost sfr...@snowman.net wrote:
Binary equality has existing precedent and is used in
numerous places in the code for good reason. Users might be confused
about the use of those semantics in those places also, but AFAICT
nobody is.
You've stated that
On Wed, Oct 2, 2013 at 1:17 PM, Jim Nasby j...@nasby.net wrote:
On 9/29/13 9:41 PM, Andrew Dunstan wrote:
On 09/29/2013 10:38 PM, Peter Eisentraut wrote:
On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
Well if these are not meant to be changed then not being able to write
them in
Stephen Frost sfr...@snowman.net wrote:
If we were consistently copying and updating the value based on
some external knowledge that the value has changed (similar to
how slony works w/ triggers that dump change sets into a table-
it doesn't consider has any value on this row changed?; the
The Technology Innovation Center in Bolzano, Italy has invited
PostgreSQL developers to attend their upcoming SFSCon on November 15th.
Their main interest is to have a discussion session with students about
contributing to PostgreSQL.
One issue they particularly want to address is the
On Thu, Oct 3, 2013 at 3:05 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Sorry for my late response. I've tried to investigate the planner code
to find out the way to integrate this custom api, and it is still in
progress.
One special handling I found was that create_join_plan() adjust
On Thu, Oct 3, 2013 at 10:53 AM, Robert Haas robertmh...@gmail.com wrote:
The point I want to make here is that we have an existing precedent to
use bitwise equality when we want to make sure that values are
equivalent for all purposes, regardless of what opclass or whatever is
in use. There
On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think the idea that we should consider a different way of handling
tabular configuration data has merit. In fact, how much sense does it
make to have these options (the ones for which this patch is being
On 23.09.2013 18:35, Bruce Momjian wrote:
On Sun, Sep 15, 2013 at 01:14:45PM +0400, Alexander Korotkov wrote:
On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangashlinnakan...@vmware.com
wrote:
There's a few open questions:
1. How are we going to handle pg_upgrade? It would be nice
On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It seems we've all but decided that we'll require reindexing GIN indexes in
9.4.
I thought the consensus in Ottawa was strongly against that. I'm not
aware that anyone has subsequently changed their position on
On Wed, Oct 2, 2013 at 5:18 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello all
there are no comments, so I'll close this topic
This feature is ready for commit
The patch looks nice and clean, and I like the feature, too. Committed.
--
Robert Haas
EnterpriseDB:
On 2013-10-03 13:03:07 -0400, Steve Singer wrote:
On 10/03/2013 12:38 PM, Andres Freund wrote:
Does your code use SELECT FOR UPDATE/SHARE on system or treat_as_catalog
tables? Greetings, Andres Freund
Yes.
It declares sl_table and sl_sequence and sl_set as catalog.
It does a
SELECT
Hello
a very ugly test shows a possibility about 100% speedup on reported
example (on small arrays, a patch is buggy and doesn't work for larger
arrays).
I updated a code to be read only
CREATE OR REPLACE FUNCTION public.fill_2d_array(rows integer, cols integer)
RETURNS integer
LANGUAGE
On 10/3/13 12:49 PM, Magnus Hagander wrote:
We could also use git receive hooks, but those would be very hard to
override when you*do* need to modify the files (which you might
within a release).
You can have the receive hook ignore the condition on existence of a file. It's
kinda kludgey,
On Oct 3, 2013, at 10:50 AM, Josh Berkus j...@agliodbs.com wrote:
But anyway, I still don’t understand why, if the function used to store the
value is immutable (as upper_inf() is), why Postgres doesn't do an index
scan. Is this something that could be improved in the planner?
Yes.
On Mon, Sep 2, 2013 at 4:35 PM, Fabrízio de Royes Mello
fabri...@timbira.com.br wrote:
The attached patch fix the items reviewed by you.
Committed with assorted revisions. In particular, I renamed the
function that discards cached sequence data, revised the wording of
the documentation, added a
On Thu, Oct 3, 2013 at 5:26 PM, Robert Haas robertmh...@gmail.com wrote:
Committed with assorted revisions. In particular, I renamed the
function that discards cached sequence data, revised the wording of
the documentation, added a regression test, and tweaked the list-free
code to pop
On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It seems we've all but decided that we'll require reindexing GIN indexes
in
9.4.
I thought the consensus in Ottawa was strongly
On 03.10.2013 23:37, Alexander Korotkov wrote:
2) Insert kluges into GIN to support both old and new formats. So, kluges
are kluges :) I don't see elegant way to do it for now, because formats are
very different.
Hmm. All you need is some code to read the old format, and a function to
convert
On Fri, Oct 4, 2013 at 12:41 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 03.10.2013 23:37, Alexander Korotkov wrote:
2) Insert kluges into GIN to support both old and new formats. So, kluges
are kluges :) I don't see elegant way to do it for now, because formats
are
very
On Thu, Oct 3, 2013 at 02:48:20PM -0400, Robert Haas wrote:
On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It seems we've all but decided that we'll require reindexing GIN indexes in
9.4.
I thought the consensus in Ottawa was strongly against that. I'm
Bruce Momjian escribió:
Agreed. I was stating only that this is easy for pg_upgrade. One cool
thing is that the upgrades completes, and the indexes are there, but
just marked as invalid until the REINDEX.
One other point Alexander made is that the new GIN indexes will be
smaller so most
On 03.10.2013 23:54, Alexander Korotkov wrote:
ItemPointers compression reduce occupied space in all normal cases. It's
not very realistic, but it could increase space in worst case. That would
lead to page split after conversion. Are we going to support such case?
Hmm, that's probably rare
Hi,
In my practice I quite often face the problem of bloated tables. I
usually use pgstattuple to perform investigations. I also create a
tool that uses UPDATEs based way to smoothly remove bloat
(https://github.com/grayhemp/pgtoolkit), and it partially depends on
pgstatuple too. To be more
* Robert Haas (robertmh...@gmail.com) wrote:
You could argue that HOT isn't user-visible, but we certainly advise
people to think about structuring their indexing in a fashion that
does not defeat HOT, so I think to some extent it is user-visible.
I do think saying HOT is user-visible is
On Fri, Oct 4, 2013 at 12:37 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas robertmh...@gmail.comwrote:
On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It seems we've all but decided that we'll require
I took a look at this patch today, and I'm pretty skeptical about
whether it's on the right track. It adds a new kind of RTE called
RTE_ALIAS, which doesn't seem particularly descriptive and alias is
used elsewhere to mean something fairly different. More generally,
I'm not convinced that adding
On Thu, Oct 3, 2013 at 5:37 PM, Sergey Konoplev gray...@gmail.com wrote:
In my practice I quite often face the problem of bloated tables. I
usually use pgstattuple to perform investigations. I also create a
tool that uses UPDATEs based way to smoothly remove bloat
My C is very rusty but the traversal of SeqTableData doesn't seem correct.
It saves the seqtab-next pointer into next, frees seqtab and then
dereferences it.
Shouldn't that last line be: seqtab = next?
Kevin.
+/*
+ * Flush cached sequence information.
+ */
+void
+ResetSequenceCaches(void)
+{
+
On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas robertmh...@gmail.com wrote:
Well, this is a general problem with any extension - somebody might
want it on a system on which the admin is unable or unwilling to
install it. But we can't put every possible extension in core.
The flip-side is that we
On Thu, Oct 3, 2013 at 3:55 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas robertmh...@gmail.com wrote:
Well, this is a general problem with any extension - somebody might
want it on a system on which the admin is unable or unwilling to
install it. But
W dniu 04.10.2013 00:28, Robert Haas pisze:
I wonder if we shouldn't be trying to handle resolution of these names
at an earlier processing stage, closer to the processor.
Maybe it can be done in parser (in flex?) but at now it seems to be more
isolated feature.
In fact, we can already get
On 10/04/2013 12:22 AM, Stephen Frost wrote:
That said, I agree that PG, in general, is more 'open' to exposing
implementation details than is perhaps ideal,
Every *real* system is more open to exposing implementation
details than is *ideal*.
One very popular implementation detail which
On Thu, Oct 3, 2013 at 6:38 PM, Kevin Hale Boyes kcbo...@gmail.com wrote:
My C is very rusty but the traversal of SeqTableData doesn't seem correct.
It saves the seqtab-next pointer into next, frees seqtab and then
dereferences it.
Shouldn't that last line be: seqtab = next?
Kevin.
+/*
+
On Thu, Oct 3, 2013 at 7:54 PM, Karol Trzcionka karl...@gmail.com wrote:
Compare EXPLAIN ANALYZE VERBOSE on your statement and on patched
workflow. I can see significant difference. And your after returns the
value after whole the work (after trigger fired) as I know (I don't know
if it is
* Hannu Krosing (ha...@krosing.net) wrote:
The main exposed implementation detail of this operator is that it is
very fast and can be recommended to be used at user level for speeding
up equal query like this
SELECT * FROM t WHERE guaranteed equal or equal
where the plain equal will only
Sergey Konoplev escribió:
On Thu, Oct 3, 2013 at 3:55 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas robertmh...@gmail.com wrote:
Well, this is a general problem with any extension - somebody might
want it on a system on which the admin is unable or
On Thu, Oct 3, 2013 at 6:36 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Greg Smith made a list some months ago of contrib modules that were
essential for forensics analysis and such. Weren't we going to do
something special about those?
It was more like two years ago. I do still think
On Fri, Oct 4, 2013 at 02:23:33AM +0400, Alexander Korotkov wrote:
I came to idea that I like option #4 more than option #2.
If we try to make new GIN work with old page formats we have to maintain 3 use
cases:
1) old GIN with old page format (because of old releases)
2) new GIN with old
On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
Shouldn't we do it for Set Constraints as well?
Oh, very good point. I missed that one. Updated
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
Heikki Linnakangas hlinnakan...@vmware.com wrote:
IMHO it would be better to remove xmin from the lock key, and vacuum
away the old predicate locks when the corresponding tuple is vacuumed.
The xmin field is only required to
On Thu, Oct 3, 2013 at 8:32 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Oct 3, 2013 at 11:50:09AM +0530, Amit Kapila wrote:
I looked at this but could not see how to easily pass the value of
'isTopLevel' down to the SELECT. All the other checks have isTopLevel
passed down from the
On Fri, Sep 27, 2013 at 6:44 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Fri, Sep 27, 2013 at 5:18 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Fri, Sep 27, 2013 at 1:28 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
Thank you for comment. I think it is good simple
On Mon, Sep 30, 2013 at 1:55 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 30, 2013 at 1:27 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
Hi Fujii-san,
(2013/09/30 12:49), Fujii Masao wrote:
73 matches
Mail list logo
