Hi Andres,
Attached is a patch which
does not CREATE DATABASE, but now the regression tests do not test the
following:
- ALTER DATABASE RENAME TO is not allowed on a database in use. Had to
remove two tests that were using this.
- ALTER DATABASE SET TABLESPACE is also not allowed on a database i
Hi All,
I have been researching bloom filters and discussed it on IRC with
RhodiumToad and David Fetter, and they pointed me to the various
places that could potentially have bloom filters, apart from the
places that already have them currently.
I have been reading the current implementation of h
On Tuesday, June 25, 2013 2:06 PM Kyotaro HORIGUCHI wrote:
> Hello,
>
> > I have tried to reproduce the problem in different m/c's, but
> couldn't
> > reproduce it.
> > I have ran tests with default configuration.
>
> I think you had reproduced it.
>
> > Output on Windows:
> > --
On June 26, 2013 5:02 AM Josh Kupershmidt wrote:
>Thanks for the feedback. Attached is a rebased version of the patch with
the two small issues noted fixed.
Patch is good, I marked the patch as ready for committer.
Regards,
Hari babu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Tuesday, June 25, 2013, Robert Haas wrote:
> On Thu, Jun 20, 2013 at 1:46 PM, Jeff Janes
> >
> wrote:
> > I've fixed a conflict, and I've removed extraneous semicolons from the C.
> >
> > I've left in the fixing of some existing bad indenting in the existing
> code,
> > which is not strictly r
On Wednesday, June 26, 2013 5:03 AM Josh Berkus wrote:
>
> >> I'll also vote for postgresql.auto.conf.
> >
> > Thanks to all of you for suggesting meaningful names. I will change
> the name of file to postgresql.auto.conf.
> > Kindly let me know if there is any objection to it.
>
> There is n
On Tuesday, June 25, 2013 10:23 AM Amit Langote wrote:
> Hi,
>
> >
> >> So our proposal on this problem is that we must ensure that master
> should
> > not make any file system level changes without confirming that the
> >> corresponding WAL record is replicated to the standby.
> >
> > How will
Hello,
Is it possible to compute VARSIZE_ANY(PTR) during debugging?
-
#define VARSIZE_ANY(PTR) \
(VARATT_IS_1B_E(PTR) ? VARSIZE_1B_E(PTR) : \
(VARATT_IS_1B(PTR) ? VARSIZE_1B(PTR) : \
VARSIZE_4B(PTR)))
#define VARA
On Sun, 2013-06-23 at 16:37 -0400, Tom Lane wrote:
> I'm un-thrilled with this as well, though for a slightly different
> reason: we have a policy that the PG sources should be tool agnostic,
> and in fact removed file-local emacs settings awhile back because of
> that.
We don't want to keep the t
On Tuesday, June 25, 2013 11:12 PM Andres Freund wrote:
> Hi,
>
> On 2013-06-16 17:19:49 -0700, Josh Berkus wrote:
> > Amit posted a new version of this patch on January 23rd. But last
> > comment on it by Tom is "not sure everyone wants this".
> >
> > https://commitfest.postgresql.org/action/pat
On Sun, 2013-06-23 at 16:03 -0400, Noah Misch wrote:
> > ((c-mode . ((c-basic-offset . 4)
> > (fill-column . 79)
>
> I don't know whether you'd consider it to fall within the scope of this
> update, but 78 is the fill-column setting that matches pgindent.
Well, well, well. I did some
On Sun, 2013-06-23 at 16:11 -0400, Andrew Dunstan wrote:
> > The idea is a very good one in principle, but my short experiment with
> > the provided .dir-locals.el didn't give me BSD style brace
> > indentation. It works if we can do those "unsafe" things, but then we
> > surely don't want to ha
On Fri, 2013-06-21 at 11:20 +0200, Dimitri Fontaine wrote:
> I've tested that on a new git clone and with the `emacs -q` command so
> as not to load any of my local setup. While the indentation seemed ok,
> the placement of the comments seems way off:
>
> Compare what you see using those commands:
I just noticed that this patch was closed with "returned with feedback"
in the commitfest app. This is good, IMV -- it's saying that the
opinion of the various people commenting on the thread is positive, and
therefore no more discussion is currently needed.
I will post an actual patch to CF2, at
Please find attached an updated patch with the said changes. I'll try to
update the other patches (if they pertain to this feedback) and update
on their respective threads (as well as on Commitfest).
Ok, this new version addresses my questions.
The patch works for me (nothing to compile, the
rec->refname, recfield->fieldname)));
> *typeid = SPI_gettypeid(rec->tupdesc, fno);
> ! *typetypmod = SPI_gettypeid(rec->tupdesc, fno);
> *value = SPI_getbinval(rec->tup, rec->tupdesc, fno,
> isnull);
>
I've recovered from messing up.
> Please let me have a bit of time to diagnose this.
I was completely messed up and walking on the wrong way. I looked
into the vacuum for UPDATEs, not DELETE's so it's quite resonable
to have such results.
The renewed test script attached shows the verbose outp
Josh Berkus writes:
> ... and if arr1, 2 and 3 are exactly the same length, this creates a
> coordinated dataset. I can even use the unnest_ordinality() extension
> function to get the ordinality of this combined dataset:
> SELECT id,
> (unnest_ordinality(arr1)).element_number as array_in
Andres Freund writes:
> But I guess given the objections on performance the combined approach is
> the way to go?
I think the documentation approach is the way to go.
It was pointed out in the pgsql-general thread about this that a naive
user might expect that, say, syntax or datatype violations
Sorry for lots of mistakes I've made,
I noticed that I was dancing on the 9.3dev at sometime, so I
reran on 9.4devel up to date, having the same result from the
view of inaccuracy of pg_class.reltuples after vacuuming.
Although, what differs from my old testset, vacuum reported that
it sanned the
Brendan Jurd wrote
> On 26 June 2013 03:17, Josh Berkus <
> josh@
> > wrote:
>> How should reviewers get credited in the release notes?
>>
>> a) not at all
>> b) in a single block titled "Reviewers for this version" at the bottom.
>> c) on the patch they reviewed, for each patch
I think some con
On Tue, Jun 25, 2013 at 6:52 PM, Kevin Grittner wrote:
> I agree though, that having an index implementation that can do the
> first level split faster than any partitioning mechanism can do is
> better, and that the main benefits of partitioning are in
> administration, *not* searching.
Indeed,
On 26 June 2013 03:17, Josh Berkus wrote:
> How should reviewers get credited in the release notes?
>
> a) not at all
> b) in a single block titled "Reviewers for this version" at the bottom.
> c) on the patch they reviewed, for each patch
A weak preference for (c), with (b) running a close secon
Folks,
(the below was already discussed on IRC)
Leaving names aside on this patch, I'm wondering about a piece of
functionality I have with the current unnest() and with the
unnest_ordinality()[1] extension: namely, the ability to unnest several
arrays "in parallel" by using unnest() in the targe
> I know it's heresy in these parts, but maybe we should consider
> adopting a non-spec syntax for this feature? In particular, it's
> really un-obvious why the FILTER clause shouldn't be inside rather
> than outside the aggregate's parens, like ORDER BY.
Well, what other DBMSes support this fea
Hi Noah,
On 2013-06-25 19:05:15 -0400, Noah Misch wrote:
> On Tue, Jun 25, 2013 at 03:01:52PM +0200, Andres Freund wrote:
> > On 2013-06-24 21:35:53 -0400, Noah Misch wrote:
> > > Simple enough, yes. The other point still stands.
> >
> > You mean performance? Primarily I still think we should fi
On 06/25/2013 06:42 AM, Szymon Guz wrote:
Hi,
I've attached a new patch. I've fixed all the problems you've found,
except for the efficiency problem, which has been described in
previous email.
thanks,
Szymon
This version of the patch addresses the issues I mentioned. Thanks for
looki
>> I'll also vote for postgresql.auto.conf.
>
> Thanks to all of you for suggesting meaningful names. I will change the
> name of file to postgresql.auto.conf.
> Kindly let me know if there is any objection to it.
There is no name you could come up with for which there would not be an
objec
On Tue, Jun 25, 2013 at 2:28 AM, Hari Babu wrote:
> Please find the review of the patch.
Thank you for reviewing!
> Code Review:
>
> +if (orig_post_opts) {
> +post_opts = strip_datadirs(orig_post_opts);
> +}
>
> No need of "{}" as the only one statement block is present in t
On Tue, Jun 25, 2013 at 03:01:52PM +0200, Andres Freund wrote:
> On 2013-06-24 21:35:53 -0400, Noah Misch wrote:
> > Simple enough, yes. The other point still stands.
>
> You mean performance? Primarily I still think we should first worry
> about correctness first and then about performance. And
Antonin Houska writes:
> On 06/25/2013 10:00 PM, Tom Lane wrote:
>> After some contemplation, I think that the most practical way to fix
>> this is for deconstruct_recurse and distribute_qual_to_rels to
>> effectively move such a qual to the place where it logically belongs;
>> that is, rather tha
Claudio Freire wrote:
> Did you try "select * from foo where (a % 16) = (1::int % 16)"?
I did. Using Robert's hashed partitioning table definitions:
test=# explain select * from foo where a = 1 and (a % 16) = (1 % 16);
QUERY PLAN
---
(Please excuse me if my proposal sounds silly, i'm still not too
advanced in this area...)
On 06/25/2013 10:00 PM, Tom Lane wrote:
After some contemplation, I think that the most practical way to fix
this is for deconstruct_recurse and distribute_qual_to_rels to
effectively move such a qual to
Hi Maciej,
I've been reviewing your patch for the ongoing commitfest. First let me say
that I think it's a great idea and provides some very useful functionality.
However, there are a few minor problems. There were a few
english/grammatical mistakes that I went ahead and fixed. Additionally, I
th
On Sat, Jun 22, 2013 at 4:32 AM, Heikki Linnakangas wrote:
> On 21.06.2013 21:55, Jeff Janes wrote:
>
>>
>> Hmm, it looks like the xlog-switch is trying to wait for itself to
> finish. The concurrent TRUNCATE is just being blocked behind the
> xlog-switch, which is stuck on itself.
>
> I wasn't a
On 19.06.2013 14:01, Amit Kapila wrote:
Observations
--
1. For small data perforamce is always good with patch.
2. For random small/large data performace is good.
3. For medium and large text and same byte data(3K,5K text, 10K,100K,500K
same byte), performance is degraded.
Wow, that
On Tue, Jun 25, 2013 at 4:32 PM, Tom Lane wrote:
> However, I find it hard to think that hash partitioning as such is very
> high on the to-do list. As was pointed out upthread, the main practical
> advantage of partitioning is *not* performance of routine queries, but
> improved bulk-data manage
On 25.06.2013 23:03, Robert Haas wrote:
On Tue, Jun 25, 2013 at 1:15 PM, Heikki Linnakangas
wrote:
I'm not sure it's a good idea to sleep proportionally to the time it took to
complete the previous fsync. If you have a 1GB cache in the RAID controller,
fsyncing the a 1GB segment will fill it u
On Tue, Jun 25, 2013 at 1:15 PM, Heikki Linnakangas
wrote:
> I'm not sure it's a good idea to sleep proportionally to the time it took to
> complete the previous fsync. If you have a 1GB cache in the RAID controller,
> fsyncing the a 1GB segment will fill it up. But since it fits in cache, it
> wi
I've been studying the bug reported at
http://www.postgresql.org/message-id/20130617235236.GA1636@jeremyevans.local
that the planner can do the wrong thing with queries like
SELECT * FROM
i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true;
I think the fundamental problem is that, b
Christopher Browne writes:
> There would indeed be merit in improving the partitioning apparatus,
> and actually, I think it's been a couple of years since there has been
> serious discussion of this.
We could certainly use a partitioning mechanism that's easier to use
than what we have now, whic
On Tue, Jun 25, 2013 at 10:17:07AM -0700, Josh Berkus wrote:
> Hackers,
>
> I'd like to take a straw poll here on how we should acknowledge
> reviewers. Please answer the below with your thoughts, either on-list
> or via private email.
>
> How should reviewers get credited in the release notes?
On 06/25/2013 12:23 PM, Tom Lane wrote:
> Josh Berkus writes:
>> However, can you tell me what exactly you are concerned about? lz4 is
>> under the BSD license, and released by Google. Why are we worried, exactly?
>
> Patents. The license on the code doesn't matter --- worst case, if
> someone
On 25 June 2013 18:17, Josh Berkus wrote:
> Hackers,
>
> I'd like to take a straw poll here on how we should acknowledge
> reviewers. Please answer the below with your thoughts, either on-list
> or via private email.
>
> How should reviewers get credited in the release notes?
>
> a) not at all
>
Josh Berkus writes:
> However, can you tell me what exactly you are concerned about? lz4 is
> under the BSD license, and released by Google. Why are we worried, exactly?
Patents. The license on the code doesn't matter --- worst case, if
someone objected, we could rewrite the algorithm ourselves
On Tue, Jun 25, 2013 at 4:15 PM, Andres Freund wrote:
>> However, can you tell me what exactly you are concerned about? lz4 is
>> under the BSD license, and released by Google.
>
> Snappy is released/copyrighted by google. lz4 by Yann Collet.
>
> Both are under BSD licenses (3 and 2 clause variant
On 2013-06-25 12:08:22 -0700, Josh Berkus wrote:
> On 06/25/2013 11:42 AM, Andres Freund wrote:
> > True. So, how do we proceed on that?
> >
> > The ASF decided it was safe to use lz4 in cassandra. Does anybody have
> > contacts over there?
> >
> > Btw, I have the feeling we hold this topic to a
I think I'd like to quibble with some of the names a bit, though.
That is a good idea, because I'm not a native English speaker and I was
not so sure for many options.
The patch adds --fill-factor, but I think we should spell it
without the hyphen: --fillfactor.
Fine with me.
I think -
On 06/25/2013 11:42 AM, Andres Freund wrote:
> True. So, how do we proceed on that?
>
> The ASF decided it was safe to use lz4 in cassandra. Does anybody have
> contacts over there?
>
> Btw, I have the feeling we hold this topic to a higher standard wrt
> patent issues than other work in postgres
On Tue, Jun 25, 2013 at 12:08 PM, Yuri Levinsky wrote:
> Guys,
> I am sorry for taking your time. The reason for my question is:
> As former Oracle DBA and now simple beginner PostgreSQL DBA I would like
> to say: the current partitioning mechanism might be improved. Sorry, it
> seems to me far b
On 06/25/2013 11:26 AM, Andres Freund wrote:
On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:
a) not at all
b) in a single block titled "Reviewers for this version" at the bottom.
c) on the patch they reviewed, for each patch
C. The idea that reviewers are somehow less than authors is ra
On 06/25/2013 11:26 AM, Andres Freund wrote:
> On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:
>>> a) not at all
>>> b) in a single block titled "Reviewers for this version" at the bottom.
>>> c) on the patch they reviewed, for each patch
>>
>> C. The idea that reviewers are somehow less than
On Tue, Jun 25, 2013 at 2:17 PM, Josh Berkus wrote:
> How should reviewers get credited in the release notes?
> c) on the patch they reviewed, for each patch
This not only makes sense, it also lets people reading release notes
know there's been a review, and how thorough it was. I know, all
chang
On 2013-06-25 12:22:31 -0400, Robert Haas wrote:
> On Thu, Jun 20, 2013 at 8:09 PM, Andres Freund wrote:
> > On 2013-06-15 12:20:28 +0200, Andres Freund wrote:
> >> On 2013-06-14 21:56:52 -0400, Robert Haas wrote:
> >> > I don't think we need it. I think what we need is to decide is which
> >> >
On 06/25/2013 01:17 PM, Josh Berkus wrote:
Hackers,
I'd like to take a straw poll here on how we should acknowledge
reviewers. Please answer the below with your thoughts, either on-list
or via private email.
How should reviewers get credited in the release notes?
a) not at all
b) in a single
On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:
> >a) not at all
> >b) in a single block titled "Reviewers for this version" at the bottom.
> >c) on the patch they reviewed, for each patch
>
> C. The idea that reviewers are somehow less than authors is rather
> disheartening.
It's not about
OK, I like this idea a lot, but I have a question. Right now, to use
this, you have to supply the startup SQL on the command line. And
that could definitely be useful. But ISTM that you might also want to
take the startup SQL from a file, and indeed you might well want to
include metacommands
On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas wrote:
> On 25.06.2013 01:24, Alexander Korotkov wrote:
>
>> On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkov
>> **wrote:
>>
>> On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas<
>>> hlinnakan...@vmware.com> wrote:
>>>
>>> That has some
On Tue, Jun 25, 2013 at 12:55 PM, Robert Haas wrote:
> Let me back up a minute. You told the OP that he could make hash
> partitioning by writing his own constraint and trigger functions. I
> think that won't work. But I'm happy to be proven wrong. Do you have
> an example showing how to do it
Yuri Levinsky escribió:
> As former Oracle DBA and now simple beginner PostgreSQL DBA I would like
> to say: the current partitioning mechanism might be improved. Sorry, it
> seems to me far behind yesterday requirements.
I don't think you'll find anybody that disagrees with this.
--
Álvaro Her
On 06/25/2013 10:17 AM, Josh Berkus wrote:
Hackers,
I'd like to take a straw poll here on how we should acknowledge
reviewers. Please answer the below with your thoughts, either on-list
or via private email.
How should reviewers get credited in the release notes?
a) not at all
b) in a singl
So, any insights on these problems?
They might not be critical, but might be silently corrupting someone's data.
2013/6/23 Rok Kralj
> Hi, after studying ITERVAL and having a long chat with RhoidumToad and
> StuckMojo on #postgresql, I am presenting you 3 bugs regarding INTERVAL.
>
> As far as
On 06/25/2013 10:46 AM, Andres Freund wrote:
> Not sure. Seems like it might be a way to spend a lot of effort without
> achieving all that much. But I can also imagine that it feels nice and
> encourages a casual reviewer/contributor.
>
> So it's either b) or c). Although I'd perhaps exclude regu
On 2013-06-25 10:17:07 -0700, Josh Berkus wrote:
> How should reviewers get credited in the release notes?
>
> a) not at all
> b) in a single block titled "Reviewers for this version" at the bottom.
> c) on the patch they reviewed, for each patch
b).
If the review was substantial enough the revi
Hi,
On 2013-06-16 17:19:49 -0700, Josh Berkus wrote:
> Amit posted a new version of this patch on January 23rd. But last
> comment on it by Tom is "not sure everyone wants this".
>
> https://commitfest.postgresql.org/action/patch_view?id=905
> ... so, what's the status of this patch?
That comm
On Mon, Jun 24, 2013 at 6:02 PM, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/14/2013 12:08 PM, Liming Hu wrote:
I have implemented the code according to Joe's
suggestion, and put the code at:
https://github.com/liminghu/fuzzystrmatch/tre
On Tue, June 25, 2013 19:17, Josh Berkus wrote:
> How should reviewers get credited in the release notes?
b) in a single block titled "Reviewers for this version" at the bottom.
> Should there be a criteria for a "creditable" review?
b) yes, they have to do more than "it compiles"
> Should re
On 25.06.2013 20:17, Josh Berkus wrote:
Hackers,
I'd like to take a straw poll here on how we should acknowledge
reviewers. Please answer the below with your thoughts, either on-list
or via private email.
How should reviewers get credited in the release notes?
a) not at all
b) in a single blo
On Mon, Jun 24, 2013 at 3:41 PM, Andres Freund wrote:
> On 2013-06-14 04:56:15 +0900, Fujii Masao wrote:
>> On Wed, Jun 12, 2013 at 9:48 PM, Stephen Frost wrote:
>> > * Magnus Hagander (mag...@hagander.net) wrote:
>> >> On Wed, Jun 12, 2013 at 1:48 PM, Andres Freund
>> >> wrote:
>> >> > On 2013
Hackers,
I'd like to take a straw poll here on how we should acknowledge
reviewers. Please answer the below with your thoughts, either on-list
or via private email.
How should reviewers get credited in the release notes?
a) not at all
b) in a single block titled "Reviewers for this version" at
On 21.06.2013 11:29, KONDO Mitsumasa wrote:
I took results of my separate patches and original PG.
* Result of DBT-2
| TPS 90%tile Average Maximum
--
original_0.7 | 3474.62 18.348328 5.739 36.977713
original_1.0 | 3469.03 18.637865 5.842 41.754
On Mon, 2013-06-24 at 20:34 -0400, Josh Kupershmidt wrote:
> This patch is in the current CommitFest, does it still need to be
> reviewed? If so, I notice that the version in pgfoundry's CVS is
> rather different than the version the patch seems to have been built
> against (presumably the pg_filed
On Tue, Jun 25, 2013 at 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> I would like to solicit opinions on whether this is a good idea. I
>> understand that the patch author thinks it's a good idea, and I don't
>> have a strong position either way. But I want to hear what other
>> people th
On Thu, Jun 20, 2013 at 8:09 PM, Andres Freund wrote:
> On 2013-06-15 12:20:28 +0200, Andres Freund wrote:
>> On 2013-06-14 21:56:52 -0400, Robert Haas wrote:
>> > I don't think we need it. I think what we need is to decide is which
>> > algorithm is legally OK to use. And then put it in.
>> >
>
On Tue, Jun 25, 2013 at 12:08:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I looked at predtest.c but I can't see how we accept >= and <= ranges,
> > but not CHECK (a % 16 == 3). It is the '%' operator? I am not sure why
> > the hashme() function is there. Wouldn't it work if hashme(
Robert Haas writes:
> I would like to solicit opinions on whether this is a good idea. I
> understand that the patch author thinks it's a good idea, and I don't
> have a strong position either way. But I want to hear what other
> people think.
If it makes pgbench more consistent with psql's com
Robert Haas escribió:
> On Thu, Jun 20, 2013 at 9:17 AM, Fabrízio de Royes Mello
> wrote:
> > On Thu, Jun 20, 2013 at 9:59 AM, Fabien COELHO wrote:
> >>> Please fix that and re-send the patch.
> >> Find attached diff wrt current master.
> > Thanks.
>
> I would like to solicit opinions on whether
On Thu, Jun 20, 2013 at 7:10 PM, Josh Kupershmidt wrote:
> I eventually tracked down the cause of this failure to a trailing ':'
> in my $LIBRARY_PATH, which causes gcc to look inside the current
> directory for a 'specs' file [1] among other things. Although I
> probably don't need that trailing
On 2013-06-25 12:11:06 -0400, Robert Haas wrote:
> On Thu, Jun 20, 2013 at 9:17 AM, Fabrízio de Royes Mello
> wrote:
> > On Thu, Jun 20, 2013 at 9:59 AM, Fabien COELHO wrote:
> >>> Please fix that and re-send the patch.
> >> Find attached diff wrt current master.
> > Thanks.
>
> I would like to
On Thu, Jun 20, 2013 at 9:17 AM, Fabrízio de Royes Mello
wrote:
> On Thu, Jun 20, 2013 at 9:59 AM, Fabien COELHO wrote:
>>> Please fix that and re-send the patch.
>> Find attached diff wrt current master.
> Thanks.
I would like to solicit opinions on whether this is a good idea. I
understand th
Guys,
I am sorry for taking your time. The reason for my question is:
As former Oracle DBA and now simple beginner PostgreSQL DBA I would like
to say: the current partitioning mechanism might be improved. Sorry, it
seems to me far behind yesterday requirements. As model for improvement
the Oracle m
Bruce Momjian writes:
> I looked at predtest.c but I can't see how we accept >= and <= ranges,
> but not CHECK (a % 16 == 3). It is the '%' operator? I am not sure why
> the hashme() function is there. Wouldn't it work if hashme() was an
> immutable function?
No. Robert's description is exact
On Fri, Jun 21, 2013 at 5:20 AM, Hitoshi Harada wrote:
> If I don't miss something, the requirement for the CONCURRENTLY option is to
> allow simple SELECT reader to read the matview concurrently while the view
> is populating the new data, and INSERT/UPDATE/DELETE and SELECT FOR
> UPDATE/SHARE ar
On Tue, Jun 25, 2013 at 8:15 AM, Michael Paquier
wrote:
> Patch updated according to comments.
Thanks for updating the patch!
When I ran VACUUM FULL, I got the following error.
ERROR: attempt to apply a mapping to unmapped relation 16404
STATEMENT: vacuum full;
Could you let me clear why toa
On Thu, Jun 20, 2013 at 1:46 PM, Jeff Janes wrote:
> I've fixed a conflict, and I've removed extraneous semicolons from the C.
>
> I've left in the fixing of some existing bad indenting in the existing code,
> which is not strictly related to my change.
OK, I like this idea a lot, but I have a qu
On Tue, Jun 25, 2013 at 11:45 AM, Bruce Momjian wrote:
> On Tue, Jun 25, 2013 at 11:15:24AM -0400, Robert Haas wrote:
>> On Tue, Jun 25, 2013 at 11:06 AM, Bruce Momjian wrote:
>> >> Not really. Constraint exclusion won't kick in for a constraint like
>> >> CHECK (hashme(a) % 16 == 3) and a WHERE
On 06/24/2013 09:16 PM, Tom Lane wrote:
Bruce Momjian writes:
Right. I don't think there are any C features we want to avoid; are
there any?
We're avoiding C99-and-later features that are not in C89, such as //
for comments, as well as more useful things. It might be time to
reconsider whe
On Tue, Jun 25, 2013 at 11:15:24AM -0400, Robert Haas wrote:
> On Tue, Jun 25, 2013 at 11:06 AM, Bruce Momjian wrote:
> >> Not really. Constraint exclusion won't kick in for a constraint like
> >> CHECK (hashme(a) % 16 == 3) and a WHERE clause of the form a = 42.
> >
> > Uh, I thought we checked
On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao wrote:
> On Thu, Jun 20, 2013 at 11:43 AM, Satoshi Nagayasu wrote:
>> (2013/06/17 4:02), Fujii Masao wrote:
>>>
>>> On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu wrote:
It is obviously easy to keep two types of function interfaces,
o
On 25.06.2013 01:24, Alexander Korotkov wrote:
On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkovwrote:
On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas<
hlinnakan...@vmware.com> wrote:
That has some obvious limitations. First of all, you can run out of
memory.
Yes, it is so. qsort sh
On Tue, Jun 25, 2013 at 11:06 AM, Bruce Momjian wrote:
>> Not really. Constraint exclusion won't kick in for a constraint like
>> CHECK (hashme(a) % 16 == 3) and a WHERE clause of the form a = 42.
>
> Uh, I thought we checked the constant against every CHECK constraint and
> only scanned partiti
Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit :
> On 06/24/2013 07:24 PM, Cédric Villemain wrote:
> > Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit :
> >> On 06/24/2013 04:02 PM, Cédric Villemain wrote:
> >>> WIth extension, we do have to set VPATH explicitely if we want to use
>
On 06/24/2013 07:24 PM, Cédric Villemain wrote:
Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit :
On 06/24/2013 04:02 PM, Cédric Villemain wrote:
WIth extension, we do have to set VPATH explicitely if we want to use
VPATH (note that contribs/extensions must not care that postgresql has
On Tue, Jun 25, 2013 at 11:02:40AM -0400, Robert Haas wrote:
> On Tue, Jun 25, 2013 at 9:21 AM, Bruce Momjian wrote:
> > On Tue, Jun 25, 2013 at 03:48:19PM +0300, Yuri Levinsky wrote:
> >> Hi,
> >>
> >> Do we have any plans to implement Hash Partitioning, maybe I missing this
> >> feature?
> >
> >
On Tue, Jun 25, 2013 at 9:21 AM, Bruce Momjian wrote:
> On Tue, Jun 25, 2013 at 03:48:19PM +0300, Yuri Levinsky wrote:
>> Hi,
>>
>> Do we have any plans to implement Hash Partitioning, maybe I missing this
>> feature?
>
> You can do it by writing your own constraint and trigger functions that
> co
On Sun, Jun 23, 2013 at 10:50 PM, Tom Lane wrote:
> David Fetter writes:
>> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
>>> I think it is OK if that gets a syntax error. If that's the "worst
>>> case" I like this approach.
>
>> I think reducing the usefulness of error message
On Tue, Jun 25, 2013 at 05:19:47PM +0300, Yuri Levinsky wrote:
> Bruce,
> Many thanks. According to PostgreSQL documentation it's only range and
> list partitions are supported. My question is: when I am following your
> advice, is PostgreSQL will do partitioning pruning on select? My
> expectation
Bruce,
Many thanks. According to PostgreSQL documentation it's only range and
list partitions are supported. My question is: when I am following your
advice, is PostgreSQL will do partitioning pruning on select? My
expectation is:
I divided my table on 128 hash partitions according let's say user_i
Hello
2013/6/25 Rushabh Lathia :
> Hi Pavel,
>
> I gone through the discussion over here and found that with this patch we
> enable the new error fields in plpgsql. Its a simple patch to expose the new
> error fields in plpgsql.
>
> Patch gets applied cleanly. make and make install too went smoo
2013/6/25 Tom Lane :
> Dean Rasheed writes:
>> On 24 June 2013 03:50, Tom Lane wrote:
>>> Going on the same principle, we could probably let FILTER be an
>>> unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a
>>> type_func_name_keyword. (I've not tried this though.)
>
>> I've not tried
1 - 100 of 130 matches
Mail list logo
