On Wed, Feb 22, 2012 at 12:27 AM, Noah Misch wrote:
> On Tue, Feb 14, 2012 at 02:04:26AM -0500, Jaime Casanova wrote:
>>
>> 1) pgstattuple-gin_spgist.patch
>> This first patch adds gin and spgist support to pgstattuple, also
>> makes pgstattuple use a ring buffer when reading tables or indexes.
>
On 08.03.2012 22:33, Kevin Grittner wrote:
I wasted a few minutes today tracking down what a couple comments
really meant to say. t_natts no longer exists as a separate field;
the equivalent value is now pulled from t_infomask2 using a macro.
Small patch to correct the comments is attached.
T
On Fri, Mar 9, 2012 at 12:46 AM, Jaime Casanova wrote:
> On Thu, Mar 8, 2012 at 8:25 AM, Robert Haas wrote:
>> On Sun, Feb 12, 2012 at 9:19 PM, Greg Smith wrote:
>>> The smaller step of automatically stripping the specified suffix from the
>>> input file name, when it matches the one we've told
On Thu, Mar 8, 2012 at 8:25 AM, Robert Haas wrote:
> On Sun, Feb 12, 2012 at 9:19 PM, Greg Smith wrote:
>> The smaller step of automatically stripping the specified suffix from the
>> input file name, when it matches the one we've told the program to expect,
>> seems like a usability improvement
I wrote:
> There are a couple of other points that make me think we need to revisit
> the PlanForeignScan API definition some more, too. ...
> So we need to break down what PlanForeignScan currently does into three
> separate steps. The first idea that comes to mind is to call them
> GetForeignRe
On Thu, Mar 8, 2012 at 11:13 PM, Robert Haas wrote:
> It's been bugging me for a while now that we don't have a prewarming
> utility, for a couple of reasons, including:
>
> 1. Our customers look at me funny when I suggest that they use
> pg_relation_filepath() and /bin/dd for this purpose.
>
wel
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for this purpose.
2. Sometimes when I'm benchmarking stuff, I want to get all the dat
On Wed, Mar 7, 2012 at 5:41 PM, Simon Riggs wrote:
>> Case #2 is certainly a problem for FrozenXID as well, because anything
>> that's marked with FrozenXID is going to look visible to everybody,
>> including our older snapshots. And I gather you're saying it's also a
>> problem for HEAP_XMIN_COM
On Thu, Mar 08, 2012 at 11:59:59PM +0200, Peter Eisentraut wrote:
> On tor, 2012-03-08 at 16:44 -0500, A.M. wrote:
> > The point of writing temp files to the /tmp/ directory is that they
> > don't need to be cleaned up.
>
> I don't think so. If everyone just left their junk lying around
> in /tmp
On Thu, Mar 08, 2012 at 10:19:05AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
> >> It looks like the patch will overwrite the logs in the current working
> >> directory, for example, if pg_upgrade is run twice in the same place. Is
> >>
On 8 March 2012 22:24, Dimitri Fontaine wrote:
We're getting there. :)
> Hi,
>
> Thom Brown writes:
>> The message returned by creating a command trigger after create index
>> is still problematic:
>
> Fixed. I'm attaching an incremental patch here, the github branch is
> updated too.
Confirm
On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut wrote:
> * It's not terribly important to me to be able to run checkers
> separately. If I wanted to do that, I would just disable or
> remove the checker.
Does this requirement mean that you want to essentially associate a
set
Hi,
Thom Brown writes:
> The message returned by creating a command trigger after create index
> is still problematic:
Fixed. I'm attaching an incremental patch here, the github branch is
updated too.
> CREATE VIEW doesn't return schema:
Fixed, and as an added bonus I fixed the CREATE SEQUENC
2012/3/8 Peter Eisentraut :
> On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
>> I might agree with you if we had more than one checker function, but
>> right now we are proposing to implement this for PL/pgsql and only
>> PL/pgsql. It seems to me that we can add that when and if a second
>>
On ons, 2012-03-07 at 21:39 +0200, Marti Raudsepp wrote:
> Is there any reason that pgxs ignores SHLIB_LINK when building
> MODULES?
No, it's just never been needed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On tor, 2012-03-08 at 16:44 -0500, A.M. wrote:
> The point of writing temp files to the /tmp/ directory is that they
> don't need to be cleaned up.
I don't think so. If everyone just left their junk lying around
in /tmp, it would fill up just like any other partition.
--
Sent via pgsql-hackers
2012/3/8 Peter Eisentraut :
> On tor, 2012-03-08 at 10:49 +0100, Albe Laurenz wrote:
>> Actually, I did when I reviewed the patch the first time round.
>> I think that the checks implemented are clearly good and useful,
>> since any problem reported will lead to an error at runtime if
>> a certain
On tor, 2012-03-08 at 10:49 +0100, Albe Laurenz wrote:
> Actually, I did when I reviewed the patch the first time round.
> I think that the checks implemented are clearly good and useful,
> since any problem reported will lead to an error at runtime if
> a certain code path in the function is taken
On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
> I might agree with you if we had more than one checker function, but
> right now we are proposing to implement this for PL/pgsql and only
> PL/pgsql. It seems to me that we can add that when and if a second
> checker function shows up, if it
On Mar 8, 2012, at 1:45 PM, Andrew Dunstan wrote:
>> So perhaps DATA_built is to be removed from pgxs.mk? And if so, is the idea
>> then that one should just put the module name in the .sql file, rather than
>> MODULE_PATHNAME in a .sql.in file?
>
> Extensions (unlike non-extension modules) sho
On 03/08/2012 04:33 PM, David E. Wheeler wrote:
On Mar 8, 2012, at 12:59 PM, Tom Lane wrote:
Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore
anyway).
Yeah, sorry, I meant `make`.
There's still some vestigial support for it in pgxs.mk, but
the future of that code is to
On Mar 8, 2012, at 4:37 PM, Peter Eisentraut wrote:
> On tor, 2012-03-08 at 10:06 -0500, A.M. wrote:
>>> The only reason I truncate them on start is that I am appending to
>> them
>>> in many places in the code, and it was easier to just truncate them
>> on
>>> start rather than to remember where
On tor, 2012-03-08 at 10:06 -0500, A.M. wrote:
> > The only reason I truncate them on start is that I am appending to
> them
> > in many places in the code, and it was easier to just truncate them
> on
> > start rather than to remember where I first write to them.
> >
> mktemps?
I don't want to
On Mar 8, 2012, at 12:59 PM, Tom Lane wrote:
> Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore
> anyway).
Yeah, sorry, I meant `make`.
> There's still some vestigial support for it in pgxs.mk, but
> the future of that code is to vanish, not get improved. You should
> not
Marti Raudsepp writes:
> But I don't feel strongly about this, maybe it's not worth
> complicating this big function further. :)
Yeah, that was kind of what I felt about it. If this patch were part of
a grand plan to make IS DISTINCT FROM smarter, that would be one thing.
But if we were to embar
On 8 March 2012 20:55, Peter Geoghegan wrote:
> On 7 March 2012 20:56, Bruce Momjian wrote:
>> Yep, good summary. Giving ourselves a few months to think about it and
>> consider other failure cases will make this a great 9.3 addition.
>
> Recent Intel processors that support SSE 4.2, including t
"David E. Wheeler" writes:
> While youre there, an issue I noticed is that the MODULE_PATHNAME
> substitutions do not work if you have your SQL files in a
> subdirectory.
Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore
anyway). There's still some vestigial support for it
On 7 March 2012 20:56, Bruce Momjian wrote:
> Yep, good summary. Giving ourselves a few months to think about it and
> consider other failure cases will make this a great 9.3 addition.
Recent Intel processors that support SSE 4.2, including those based on
the core microarchitecture, can calculat
I wasted a few minutes today tracking down what a couple comments
really meant to say. t_natts no longer exists as a separate field;
the equivalent value is now pulled from t_infomask2 using a macro.
Small patch to correct the comments is attached.
-Kevin
*** a/src/backend/access/common/heapt
On Mar 8, 2012, at 12:20 PM, Andrew Dunstan wrote:
> It works fine if you don't need to do any file conversions (i.e. if you don't
> have "input" or "output" directories). But file_textarray_fdw does.
>
> Here's a patch that I think fixes the problem.
While you’re there, an issue I noticed is t
On 03/08/2012 02:59 PM, David E. Wheeler wrote:
On Mar 8, 2012, at 10:22 AM, Andrew Dunstan wrote:
This seems like an outright bug. I don't recall any discussion on it. Maybe
nobody's come across it before. ISTM the correct behaviour would be to put
converted sql files in $inputdir/sql and co
On Mar 8, 2012, at 10:22 AM, Andrew Dunstan wrote:
> This seems like an outright bug. I don't recall any discussion on it. Maybe
> nobody's come across it before. ISTM the correct behaviour would be to put
> converted sql files in $inputdir/sql and converted results files in
> $outputdir/expect
On Mar 8, 2012, at 11:27 AM, Andrew Dunstan wrote:
> Yeah. Note too that this is at best dubious:
>
>CREATE OR REPLACE FUNCTION json_cmp(
>json,
>json
>) RETURNS INTEGER LANGUAGE SQL STRICT IMMUTABLE AS $$
>SELECT bttextcmp($1::text, $2::text);
>$$;
>
>
> Two
On Mar 8, 2012, at 11:16 AM, Tom Lane wrote:
>> This seems to work.
>
> Urk. You really ought to provide the whole opclass (all 5 operators).
> I'm not sure what will blow up if you leave it like that, but it won't
> be pretty.
Yes, I expect to have to fill in gaps as I go. These are just for u
On 03/08/2012 02:16 PM, Tom Lane wrote:
"David E. Wheeler" writes:
CREATE OPERATOR CLASS json_ops
DEFAULT FOR TYPE JSON USING btree AS
OPERATOR3 = (json, json),
FUNCTION1 json_cmp(json, json);
This seems to work.
Urk. You really ought to provide the whole op
On Thu, Mar 08, 2012 at 11:30:52AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Mar 07, 2012 at 07:51:42PM -0500, Tom Lane wrote:
> >> On reflection my idea above is wrong; for example assume that we have a
> >> column with 900 arrays of length 1 and 100 arrays of length 2. Going by
>
"David E. Wheeler" writes:
> CREATE OPERATOR CLASS json_ops
> DEFAULT FOR TYPE JSON USING btree AS
> OPERATOR3 = (json, json),
> FUNCTION1 json_cmp(json, json);
> This seems to work.
Urk. You really ought to provide the whole opclass (all 5 operators).
I'm not sure
On Mar 7, 2012, at 8:23 PM, Tom Lane wrote:
> You have not told the system that your operator is equality for the
> datatype. It's just a random operator that happens to be named "=".
> We try to avoid depending on operator names as cues to semantics.
>
> You need to incorporate it into a defaul
I think I've complained about this before, but:
When you are preparing a patch, fixing the comments is JUST AS IMPORTANT
AS FIXING THE CODE. Obsolete comments are worse than useless. Look to
see if you've invalidated something in the head-of-file comments about
the module you're changing. Look
I have just found, after an hour or two of frustration, that pg_regress'
--inputdir and --outputdir options don't play nicely with the
convert_sourcefiles routines. In effect these options are ignored as
destinations for converted files, and the destination for converted
files is apparently alw
On Thu, Mar 8, 2012 at 19:35, Tom Lane wrote:
> Uh ... how much do we care about that? I can't say that I've heard many
> people complain about the fact that IS [NOT] DISTINCT FROM is poorly
> optimized -- which it is, in general, and this patch chips away at that
> only a tiny bit, not enough to
Marti Raudsepp writes:
> This patch enables a simple optimization in
> eval_const_expressions_mutator. If we know that one argument to
> DistinctExpr is NULL then we can optimize it to a NullTest, which can
> be an indexable expression.
Uh ... how much do we care about that? I can't say that I'v
Hi list,
This patch enables a simple optimization in
eval_const_expressions_mutator. If we know that one argument to
DistinctExpr is NULL then we can optimize it to a NullTest, which can
be an indexable expression.
For example the query:
EXPLAIN (costs off) SELECT * FROM foo WHERE j IS NOT DISTIN
On 8 March 2012 14:44, Tom Lane wrote:
> I thought the proposal was to add it to (1) pg_stat_statement and (2)
> EXPLAIN, both of which are not in the normal code execution path.
> pg_stat_statement is already a drag on a machine with slow gettimeofday,
> but it's not clear why users of it would t
Noah Misch writes:
> On Wed, Mar 07, 2012 at 07:51:42PM -0500, Tom Lane wrote:
>> On reflection my idea above is wrong; for example assume that we have a
>> column with 900 arrays of length 1 and 100 arrays of length 2. Going by
>> what I said, we'd reduce the histogram to {1,2}, which might accu
Noah Misch wrote:
> On Fri, Mar 02, 2012 at 03:45:38PM -0500, Robert Haas wrote:
>> SELECT SUM(1) FROM (SELECT * FROM randomtext ORDER BY t) x;
>> [13% faster with patch for C collation; 7% faster for UTF8]
>> I had hoped for more like a 15-20% gain from this approach, but
>> it didn't happe
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian wrote:
> >> Any ideas about improving the error reporting more generally, so that
> >> when reloading the dump fails, the user can easily see what went
> >> belly-up, even if they didn't u
Shigeru Hanada writes:
> [ pgsql_fdw_v15.patch ]
I've been looking at this patch a little bit over the past day or so.
I'm pretty unhappy with deparse.c --- it seems like a real kluge,
inefficient and full of corner-case bugs. After some thought I believe
that you're ultimately going to have to
Robert Haas writes:
> Considering that this constitutes a major redesign and that the
> updated patch hasn't been posted over a month later, it seems past
> time to mark this Returned with Feedback. So I've done that.
I was hoping to be able to code that while the CF is running but
obviously tha
Hello
there are other version related to your last comments. I removed magic
constants.
This is not merged with Peter's changes. I'll do it tomorrow. Probably
there will be some bigger changes in header files, but this can be
next step.
Regards
Pavel
2012/3/8 Alvaro Herrera :
> Hi guys,
>
> so
On Wed, Mar 07, 2012 at 07:51:42PM -0500, Tom Lane wrote:
> Alexander Korotkov writes:
> > True. If (max count - min count + 1) is small, enumerating of frequencies
> > is both more compact and more precise representation. Simultaneously,
> > if (max count - min count + 1) is large, we can run out
On Fri, Mar 02, 2012 at 03:45:38PM -0500, Robert Haas wrote:
> SELECT SUM(1) FROM (SELECT * FROM randomtext ORDER BY t) x;
>
> On unpatched master, this takes about 416 ms (plus or minus a few).
> With the attached patch, it takes about 389 ms (plus or minus a very
> few), a speedup of about 7%.
>
Bruce Momjian writes:
> On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
>> It looks like the patch will overwrite the logs in the current working
>> directory, for example, if pg_upgrade is run twice in the same place. Is
>> that intentional? I had imagined that the logs would have been dump
On Wed, Mar 07, 2012 at 04:57:12PM -0500, Robert Haas wrote:
> On Sat, Feb 25, 2012 at 12:57 AM, Noah Misch wrote:
> > Thanks. ?While testing a crashing function, I noticed that my above patch
> > added some noise to psql output when the server crashes:
> >
> > [local] test=# select crashme();
> >
On Mar 8, 2012, at 10:00 AM, Bruce Momjian wrote:
>
> Yes. I was afraid that continually appending to a log file on every run
> would be too confusing. I could do only appends, or number the log
> files, that those seemed confusing.
>
>> the /tmp directory so that one can compare results if th
On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
>
> On Mar 7, 2012, at 11:39 PM, Bruce Momjian wrote:
>
> > On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote:
> >> OK, combining your and Robert's ideas, how about I have pg_upgrade write
> >> the server log to a file, and the pg_
Peter Geoghegan writes:
> On 8 March 2012 13:09, Robert Haas wrote:
>> Then again, considering that gettimeofday is kinda
>> expensive, I suppose that would have to be optional if we were to have
>> it at all.
> +1. I'm not opposed to having such a mechanism, but it really ought to
> impose exa
Robert Haas writes:
> Dimitri, are you going to post an updated patch for this CF?
Yes, I intend to do that. Not sure about diverting from the command
trigger patch while Thom is full speed on reviewing and helping me write
the full covering test cases, though.
Regards,
--
Dimitri Fontaine
http
On Wed, Feb 29, 2012 at 9:39 PM, Fujii Masao wrote:
>> Do we have an updated patch? Fujii?
>
> No. I believe that the author Jim will submit the updated version.
Jim, are you going to submit an updated version?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Mar 7, 2012, at 11:39 PM, Bruce Momjian wrote:
> On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote:
>> OK, combining your and Robert's ideas, how about I have pg_upgrade write
>> the server log to a file, and the pg_dump output to a file (with its
>> stderr), and if pg_upgrade fail
On 8 March 2012 13:09, Robert Haas wrote:
> Then again, considering that gettimeofday is kinda
> expensive, I suppose that would have to be optional if we were to have
> it at all.
+1. I'm not opposed to having such a mechanism, but it really ought to
impose exactly no overhead on the common case
On Sun, Feb 12, 2012 at 9:19 PM, Greg Smith wrote:
> The smaller step of automatically stripping the specified suffix from the
> input file name, when it matches the one we've told the program to expect,
> seems like a usability improvement unlikely to lead to bad things though.
> I've certainly
On Sat, Jan 28, 2012 at 8:57 AM, Simon Riggs wrote:
> On Thu, Jan 26, 2012 at 5:27 AM, Fujii Masao wrote:
>
>> One thing I would like to ask is that why you think walreceiver is more
>> appropriate for writing XLOG_END_OF_RECOVERY record than startup
>> process. I was thinking the opposite, becau
On Tue, Feb 28, 2012 at 5:34 AM, Hitoshi Harada wrote:
> Quickly reviewed the patch and found some issues.
>
> - There are some mixture of pg_extension_feature and pg_extension_feature"s"
> - The doc says pg_extension_feature"s" has four columns but it's not true.
> - Line 608 is bad. In the loop,
On Thu, Jan 26, 2012 at 12:40 PM, Dimitri Fontaine
wrote:
> So I'm going to prepare the next version of the patch with this design:
Considering that this constitutes a major redesign and that the
updated patch hasn't been posted over a month later, it seems past
time to mark this Returned with Fe
On Fri, Feb 24, 2012 at 9:01 PM, Noah Misch wrote:
> I consider these the core changes needed to reach Ready for Committer:
>
> - Fix crash in array_replace(arr, null, null).
> - Don't look through the domain before calling can_coerce_type().
> - Compare operator family of pfeqop and TYPECACHE_EQ_
On Wed, Mar 7, 2012 at 9:59 PM, Fujii Masao wrote:
>> I'd like to have the planning time in a number of other places as
>> well, such as EXPLAIN, and maybe statistics views.
>
> +1 for EXPLAIN. But which statistics views are in your mind?
I don't know. I'm not sure if it's interesting to be able
On Tue, Mar 6, 2012 at 10:37 PM, Tom Lane wrote:
> Applied with minor editorialization (mainly just improving the
> comments).
Thanks and kudos to all the reviewers!
regards,
Martin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Hi guys,
sorry, I'm stuck in an unfamiliar webmail.
I checked the patch Petr just posted.
http://archives.postgresql.org/pgsql-hackers/2012-03/msg00482.php
I have two comments. First, I notice that the documentation changes
has two places that describe the columns that a function checker
return
On 03/08/2012 08:35 AM, Pavel Stehule wrote:
Here is updated patch (with regress tests, with documentation).
I removed a CHECK FUNCTION and CHECK TRIGGER statements and replaced
it by pg_check_function and pg_check_trigger like Tom proposed.
The core of this patch is same - plpgsql checker, onl
On 8 March 2012 01:45, Fujii Masao wrote:
> On Thu, Mar 8, 2012 at 10:36 AM, Thom Brown wrote:
>> I've just tried using pg_basebackup to take a backup of a standby with
>> "-x stream" but it never finishes.
>
> Thanks for the report! This is the same problem as I reported before.
> We are now dis
On Thu, Mar 8, 2012 at 02:45, Fujii Masao wrote:
> On Thu, Mar 8, 2012 at 10:36 AM, Thom Brown wrote:
>> I've just tried using pg_basebackup to take a backup of a standby with
>> "-x stream" but it never finishes.
>
> Thanks for the report! This is the same problem as I reported before.
> We are
Robert Haas wrote:
> Well, I guess I'm still of the opinion that the real question is
> whether the particular lint checks that Pavel's implemented are good
> and useful things. Has anyone spent any time looking at *that*?
Actually, I did when I reviewed the patch the first time round.
I think th
73 matches
Mail list logo
