On Tue, Jun 25, 2013 at 4:32 PM, Tom Lane t...@sss.pgh.pa.us 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
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,
On Sat, Jun 22, 2013 at 4:32 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
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
(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
Claudio Freire klaussfre...@gmail.com 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
Antonin Houska antonin.hou...@gmail.com 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;
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 CASE
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
objection.
On Tue, Jun 25, 2013 at 2:28 AM, Hari Babu haribabu.ko...@huawei.com 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
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
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 first worry
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
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 target
On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com 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
On Tue, Jun 25, 2013 at 6:52 PM, Kevin Grittner kgri...@ymail.com 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*
Brendan Jurd wrote
On 26 June 2013 03:17, Josh Berkus lt;
josh@
gt; 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 consideration
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
Andres Freund and...@2ndquadrant.com 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
Josh Berkus j...@agliodbs.com 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,
I've recovered from messing up.
snip
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
);
*value = SPI_getbinval(rec-tup, rec-tupdesc, fno,
isnull);
break;
}
Once you confirm, I will go ahead reviewing it.
Hi Jeevan,
Oopsies, I've updated the patch and attached it.
Regards,
Mark
add_spigettypmod-20130625.diff
Description: Binary data
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,
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
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:
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 have a user
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 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.
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 tool
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
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 you take care of
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 no name you
On Tuesday, June 25, 2013, Robert Haas wrote:
On Thu, Jun 20, 2013 at 1:46 PM, Jeff Janes
jeff.ja...@gmail.comjavascript:;
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,
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
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:
---
postgres=#
101 - 135 of 135 matches
Mail list logo
