On Mon, Sep 30, 2013 at 1:55 PM, Amit Kapila wrote:
> On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao wrote:
>> On Mon, Sep 30, 2013 at 1:27 PM, KONDO Mitsumasa
>> wrote:
>>> Hi Fujii-san,
>>>
>>>
>>> (2013/09/30 12:49), Fujii Masao wrote:
On second thought, the patch could compress WAL very
On Fri, Sep 27, 2013 at 6:44 PM, Sawada Masahiko wrote:
> On Fri, Sep 27, 2013 at 5:18 PM, Pavan Deolasee
> wrote:
>> On Fri, Sep 27, 2013 at 1:28 PM, Sawada Masahiko
>> wrote:
>>>
>>>
>>> >
>>>
>>> Thank you for comment. I think it is good simple idea.
>>> In your opinion, if synchronous_transf
On Thu, Oct 3, 2013 at 8:32 PM, Bruce Momjian 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 utility
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
> Heikki Linnakangas 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 tha
On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund 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 patch at
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 6:36 PM, Alvaro Herrera 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 that that kind of
eff
Sergey Konoplev escribió:
> On Thu, Oct 3, 2013 at 3:55 PM, Peter Geoghegan wrote:
> > On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas 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.
* 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 or
>
> where the plain will only be called when fast
On Thu, Oct 3, 2013 at 7:54 PM, Karol Trzcionka 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 needed or not
On Thu, Oct 3, 2013 at 6:38 PM, Kevin Hale Boyes 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.
>
> +/*
> + * Flush
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 sur
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 ap
On Thu, Oct 3, 2013 at 3:55 PM, Peter Geoghegan wrote:
> On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas 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 ex
On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas 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 could have made an
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 5:37 PM, Sergey Konoplev 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
> (https://github.com/grayhemp/pgtoolkit), an
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 Fri, Oct 4, 2013 at 12:37 AM, Alexander Korotkov wrote:
> On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas wrote:
>
>> On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
>> wrote:
>> > It seems we've all but decided that we'll require reindexing GIN
>> indexes in
>> > 9.4.
>>
>> I thought the cons
* 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 rea
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 precis
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
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 eno
On Thu, Oct 3, 2013 at 02:48:20PM -0400, Robert Haas wrote:
> On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
> 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 tha
On Fri, Oct 4, 2013 at 12:41 AM, Heikki Linnakangas 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 different.
>>
>
> Hm
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 Thu, Oct 3, 2013 at 10:48 PM, Robert Haas wrote:
> On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
> 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 anyo
On Thu, Oct 3, 2013 at 5:26 PM, Robert Haas 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 items off one after
On Mon, Sep 2, 2013 at 4:35 PM, Fabrízio de Royes Mello
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 regression test, and t
On Oct 3, 2013, at 10:50 AM, Josh Berkus 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. This is cle
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, bu
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 plpgs
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
> S
On Wed, Oct 2, 2013 at 5:18 AM, Pavel Stehule 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: http://www.enterprisedb.com
The Enterpr
On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
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 the
topic. Bruce is ri
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 Linnakangas
wrote:
There's a few open questions:
1. How are we going to handle pg_upgrade? It would be nice to be able to
read t
On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
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
> written) be GUCs in the firs
On Thu, Oct 3, 2013 at 10:53 AM, Robert Haas 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 are not a ton of t
On Thu, Oct 3, 2013 at 3:05 AM, Kohei KaiGai 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
> root->curOuterRels pri
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 possibility
Stephen Frost 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
> user did an u
On Wed, Oct 2, 2013 at 1:17 PM, Jim Nasby 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
the
On Thu, Oct 3, 2013 at 11:12 AM, Stephen Frost 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 a few ti
Steve Singer 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 think the main
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.
On Wed, Oct 2, 2013 at 7:17 PM, Jim Nasby 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
>>
Bruce Momjian 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, they
>>
On Oct 2, 2013, at 5:07 AM, Merlin Moncure 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
> > ---
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 S
On Sat, Sep 28, 2013 at 8:42 AM, Marko Tiikkaja 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 t
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 (
>
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
* 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 thou
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. :-)
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 Mo
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 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 variou
On 09/30/2013 09:08 AM, Kevin Grittner wrote:
Steve Singer 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:
*=,
*<>,
*<,
*<=,
On 2013-10-01 00:28:55 +0200, Bernd Helmle wrote:
>
>
> --On 30. September 2013 19:00:06 +0200 Andres Freund
> wrote:
>
> >>HEAD (default):
> >>
> >>tps = 181738.607247 (including connections establishing)
> >>tps = 182665.993063 (excluding connections establishing)
> >>
> >>HEAD (padding + 16
On Mon, Sep 30, 2013 at 5:28 PM, Bernd Helmle wrote:
>
>
> --On 30. September 2013 19:00:06 +0200 Andres Freund
> wrote:
>
>>> HEAD (default):
>>>
>>> tps = 181738.607247 (including connections establishing)
>>> tps = 182665.993063 (excluding connections establishing)
>>>
>>> HEAD (padding + 16 p
MauMau escribió:
> From: "Alvaro Herrera"
> >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 Herrerahttp://www.2ndQuadran
Heikki Linnakangas 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 is inserted to the s
From: "Alvaro Herrera"
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 (pgsql-hackers@postgresql.org)
To m
On Wed, Oct 2, 2013 at 6:12 AM, Peter Eisentraut 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))
> > {
On Tue, Oct 1, 2013 at 11:37 PM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
>> On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane wrote:
>> > Peter Eisentraut writes:
>> >> On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote:
>> >>> Given that, I'm fine with just bumping the version on borka to
> 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
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 wrote:
> On 10/2/13 5:12 AM, Asif Naeem wrote:
> > Neither git nor patch command apply the patch successfully. Can you
> > please guide ?. Thanks.
>
On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur 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 session as well.
On 03.10.2013 01:05, Kevin Grittner wrote:
Andres Freund wrote:
On 2013-10-01 07:41:46 -0700, Kevin Grittner wrote:
Andres Freund wrote:
A better solution probably is to promote tuple-level locks if
they exist to a relation level one upon freezing I guess?
It would be sufficient to promot
2013/10/3 Tom Lane
> Pavel Stehule 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
> v
Pavel Stehule 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 probably safe, but it's
71 matches
Mail list logo
