On 2013-06-26 23:42:55 -0700, Peter Geoghegan wrote:
> On Wed, Jun 26, 2013 at 11:27 PM, Andres Freund
> wrote:
> > Why not do this from a function/background worker in the backend where
> > you can go via the buffer manager to avoid torn pages et al. If you use
> > a buffer strategy the cache po
On Wed, Jun 26, 2013 at 11:27 PM, Andres Freund wrote:
> Why not do this from a function/background worker in the backend where
> you can go via the buffer manager to avoid torn pages et al. If you use
> a buffer strategy the cache poisoning et al should be controlleable.
I had considered that, b
On Thursday, June 27, 2013 11:26 AM Andres Freund wrote:
> On 2013-06-27 11:16:25 +0530, Amit Kapila wrote:
> > On Wednesday, June 26, 2013 10:19 PM Fujii Masao wrote:
> > > On Wed, Jun 26, 2013 at 8:57 PM, Amit Kapila
>
> > > >> > One more use case for which this utility was done is as
> below:
On 2013-06-26 21:18:49 -0700, Peter Geoghegan wrote:
> On Wed, Jun 26, 2013 at 8:27 PM, Tom Lane wrote:
> > TBH, I've always been annoyed that pg_filedump is GPL and so there's no
> > way for us to just ship it in contrib. (That stems from Red Hat
> > corporate policy of a dozen years ago, but th
Latest patch looks good to me.
Regards,
Rushabh
On Wed, Jun 26, 2013 at 11:21 PM, Pavel Stehule wrote:
> Hello
>
> updated patch with some basic doc
>
> Regards
>
> Pavel
>
>
> 2013/6/26 Rushabh Lathia :
> >
> >
> >
> > On Wed, Jun 26, 2013 at 5:11 PM, Pavel Stehule
> > wrote:
> >>
> >> 2013/6
On 2013-06-26 20:07:40 -0400, Tom Lane wrote:
> > I don't see how we could trigger the conditions for EINPROGRESS on
> > windows that msdn lists, but since we need it on unixoid systems and its
> > valid to treat the connect as partiall successfull on windows, there
> > seems little benefit in drop
On 2013-06-27 11:16:25 +0530, Amit Kapila wrote:
> On Wednesday, June 26, 2013 10:19 PM Fujii Masao wrote:
> > On Wed, Jun 26, 2013 at 8:57 PM, Amit Kapila
> > >> > One more use case for which this utility was done is as below:
> > >> > It will be used to decide that on new-standby (old-master
On Wednesday, June 26, 2013 10:19 PM Fujii Masao wrote:
> On Wed, Jun 26, 2013 at 8:57 PM, Amit Kapila
> wrote:
> > On Wednesday, June 26, 2013 4:40 PM Andres Freund wrote:
> >> Hi Amit,
> >>
> >> On 2013-06-26 16:22:28 +0530, Amit Kapila wrote:
> >> > On Wednesday, June 26, 2013 1:20 PM Andres Fr
Dear Mitsumasa,
As I know, famous NoSQL benchmark program which was called YCSB is display
latency measure. I think that TPS indicates system performance for system
administrator, and latency indicates service performance for end user, in
custom benchmarks.
Sure. I agree that both informati
Hi,
I just realized that in the original incarnation of lock_timeout,
I used ERRCODE_LOCK_NOT_AVAILABLE (to be consistent with NOWAIT)
but the patch that was accepted into 9.3 contained ERRCODE_QUERY_CANCELED
which is the same as for statement_timeout.
Which would be more correct?
Thanks in adv
On Wed, Jun 26, 2013 at 8:27 PM, Tom Lane wrote:
> TBH, I've always been annoyed that pg_filedump is GPL and so there's no
> way for us to just ship it in contrib. (That stems from Red Hat
> corporate policy of a dozen years ago, but the conflict is real anyway.)
> If somebody is sufficiently exc
(2013/06/26 20:15), Heikki Linnakangas wrote:
On 26.06.2013 11:37, KONDO Mitsumasa wrote:
On Tue, Jun 25, 2013 at 1:15 PM, Heikki Linnakangas
Hmm, so the write patch doesn't do much, but the fsync patch makes
the response
times somewhat smoother. I'd suggest that we drop the write patch
for now
Josh Berkus writes:
> On 06/26/2013 12:08 PM, Fabien COELHO wrote:
>> I have been suggesting something upon that line in some of the reviews
>> I've posted about Robins non regression tests, if they were to be
>> rejected on the basis that they add a few seconds for checks. They are
>> well made t
Jeff Davis writes:
> 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
>> agains
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Attached patch has all changes against trunk code.
There is added a function for conversion from Postgres numeric to
Python Decimal. The Decimal type is taken from cdecimal.Decimal, if it
is available. It is an external library, quite fast, but may
Andrew Gierth writes:
> Possibly significant in this context is that there is a proof-of-concept
> patch in development for another part of T612, namely inverse
> distribution functions (e.g. percentile_disc and percentile_cont) which
> should be available by the next CF, and which will require a
Hello Fevien,
Thank you for your fast work and reply. I try to test your new patch until next
week.
(2013/06/26 20:16), Fabien COELHO wrote:
Here is a v4 that takes into account most of your points: The report is
performed
for all threads by thread 0, however --progress is not supported unde
On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao wrote:
> On Wed, Jun 26, 2013 at 2:36 PM, Hari Babu wrote:
>> 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.
>
> The following descripti
On Sun, 2013-06-23 at 12:24 +0800, rui hua wrote:
> Regression tests are all succeed, but several problems have be found while
> ding some simple test. The updated document said that the points used in
> the output are not necessarily the points used on input. I understand that
> as long as they a
On Mon, Jun 24, 2013 at 01:41:51PM +, Albe Laurenz wrote:
> Noah Misch wrote:
> >> If fixing the behaviour is undesirable, at least the documentation
> >> should be fixed.
> >
> > A brief documentation mention sounds fine. Perhaps add a paragraph on
> > constant folding in general and referen
On Thu, Jun 27, 2013 at 12:02 AM, Alvaro Herrera
wrote:
> Amit Langote escribió:
>
>> The segfault in question happens at line 1141:
>>
>> off = att_align_pointer(off, thisatt->attalign, -1, tp + off);
>>
>> char *tp; /* ptr to tuple data */
>> longoff;
On Tue, Jun 25, 2013 at 5:40 PM, Brendan Jurd wrote:
> 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 ea
Andres Freund writes:
> On 2013-06-26 12:07:54 -0400, Tom Lane wrote:
>> ... I wonder whether it's safe to remove the case altogether. Could
>> anyone research the situation for non-blocking connect() on Windows?
>> Perhaps on Windows we shouldn't test for EINPROGRESS at all?
> The way EWOULDBLO
On Mon, May 13, 2013 at 7:26 AM, Noah Misch wrote:
> A memory chunk allocated through the existing palloc.h interfaces is
> limited
> to MaxAllocSize (~1 GiB). This is best for most callers; SET_VARSIZE()
> need
> not check its own 1 GiB limit, and algorithms that grow a buffer by
> doubling
> n
Folks,
Wanted to give you the below testing emails from DHAVAL JAISWAL. He's
been testing 9.3's streaming-only cascading replication, and so far it
works as advertised. What he found in his tests was:
a) he could not remaster to a former replica which was behind the relica
he was trying to rema
On 27/06/13 07:12, Josh Berkus wrote:
On 06/26/2013 12:02 PM, Alvaro Herrera wrote:
See the entry for foreign key locks:
Prevent non-key-field row updates from locking foreign key rows (Álvaro
Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp)
I am the author of most
On 06/26/2013 02:49 PM, Jeff Janes wrote:
> I see in the commitfest app it is set to "Waiting on Author" (but I don't
> know who "maiku41" is).
Mike Blackwell, who's helping track patches for the CommitFest.
It's been our practice since the 9.3 cycle that patches which are still
under contentious
On Thu, Jun 27, 2013 at 1:15 AM, Dimitri Fontaine
wrote:
> Josh Berkus writes:
>> Well, one of the other "prizes" which occurred to me today would be a
>> pgCon lottery. That is, each review posted by a non-committer would go
>> in a hat, and in February we would draw one who would get a free
>>
Jeff Janes escribió:
> I see in the commitfest app it is set to "Waiting on Author" (but I don't
> know who "maiku41" is).
Yeah, that guy is misterious. I'm guessing the Mike Blackwell person
Josh mentioned in his "week 1" report.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Po
On Tue, Jun 18, 2013 at 12:09 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
>
> Jeff's patch seems to somewhat alleviate the huge fall in performance I'm
> otherwise seeing without the nonlocked-test patch. With the nonlocked-test
> patch, if you squint you can see a miniscule benefit.
On Wed, Jun 26, 2013 at 09:04:34PM +0100, Dean Rasheed wrote:
> On 26 June 2013 19:32, Noah Misch wrote:
> > On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
> > md5_agg() is well-defined and not cryptographically novel, and your use case
> > is credible. However, not every useful-s
On Tue, Jun 25, 2013 at 10:17 AM, Josh Berkus wrote:
> How should reviewers get credited in the release notes?
Without getting into how we do this, I thought it might be helpful to
share the reasons why I believe recognizing and expressing gratitude
to reviewers is a helpful, useful and gratifyi
On 26 June 2013 22:08, Szymon Guz wrote:
> On 26 June 2013 21:59, Peter Eisentraut wrote:
>
>> On 6/26/13 7:03 AM, Szymon Guz wrote:
>> > I've checked the patch, everything looks great.
>> > I've attached it to this email with changed name, just for consistent
>> > naming in commitfest app.
>>
>
On 6/26/13 4:04 PM, Dean Rasheed wrote:
> A quick google search reveals several people asking for something like
> this, and people recommending md5(string_agg(...)) or
> md5(string_agg(md5(...))) based solutions, which are doomed to failure
> on larger tables.
The thread discussed several other o
On Sun, Jun 23, 2013 at 2:45 AM, Simon Riggs wrote:
> On 23 June 2013 03:16, Stephen Frost wrote:
>
> > Will think on it more.
>
> Some other thoughts related to this...
>
> * Why are we building a special kind of hash table? Why don't we just
> use the hash table code that we in every other pla
On 26 June 2013 21:59, Peter Eisentraut wrote:
> On 6/26/13 7:03 AM, Szymon Guz wrote:
> > I've checked the patch, everything looks great.
> > I've attached it to this email with changed name, just for consistent
> > naming in commitfest app.
>
> Could the setup of the decimal.Decimal constructor
On 26 June 2013 19:32, Noah Misch wrote:
> On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
>> I've been playing around with the idea of an aggregate that computes
>> the sum of the md5 hashes of each of its inputs, which I've called
>> md5_total() for now, although I'm not particular
On 6/26/13 7:03 AM, Szymon Guz wrote:
> I've checked the patch, everything looks great.
> I've attached it to this email with changed name, just for consistent
> naming in commitfest app.
Could the setup of the decimal.Decimal constructor be moved into
PLyDecimal_FromNumeric() and kept in a static
On 26 June 2013 21:10, Josh Berkus wrote:
>
> > Is it enough to provide the description in the commitfest app, or is that
> > better to send an email and provide link in commitfest?
>
> Better to do it here, on the list.
>
> > This is a patch only with regression tests, is that enough to write
>
On Wed, Jun 26, 2013 at 7:01 AM, k...@rice.edu wrote:
> On Wed, Jun 26, 2013 at 03:47:43PM +0200, Markus Wanner wrote:
> > On 06/25/2013 11:52 PM, Kevin Grittner wrote:
> > > At least until we have parallel
> > > query execution. At *that* point this all changes.
> >
> > Can you elaborate on tha
On 06/26/2013 12:08 PM, Fabien COELHO wrote:
> I have been suggesting something upon that line in some of the reviews
> I've posted about Robins non regression tests, if they were to be
> rejected on the basis that they add a few seconds for checks. They are
> well made to test corner cases quite s
On 06/26/2013 12:02 PM, Alvaro Herrera wrote:
> See the entry for foreign key locks:
>
> Prevent non-key-field row updates from locking foreign key rows (Álvaro
> Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp)
>
> I am the author of most of the code, yet I chose to add
> Is it enough to provide the description in the commitfest app, or is that
> better to send an email and provide link in commitfest?
Better to do it here, on the list.
> This is a patch only with regression tests, is that enough to write
> something like: "This patch applies cleanly on trunk co
I was intending to suggest that much of what Robins has submitted
doesn't belong in the core regression tests, but could usefully be put
into an optional set of "big" regression tests. We already have a
"numeric_big" test in that spirit. What seems to be lacking is an
organizational principle
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
Hello
remastered version
Regards
Pavel
2013/6/26 Jeevan Chalke :
> Hi Pavel
>
>
> On Sat, Jan 26, 2013 at 9:22 AM, Pavel Stehule
> wrote:
>>
>> Hello Tom
>>
>> you did comment
>>
>> ! <><--><--> * Non-null argument had better be an array.
>> The parser doesn't
>> ! <><--><-
On 26 June 2013 20:57, Szymon Guz wrote:
> On 26 June 2013 20:55, Josh Berkus wrote:
>
>> On 06/26/2013 12:29 AM, Szymon Guz wrote:
>> > OK, so I think this patch can be committed, I will change the status.
>>
>> Can we have a full review before you mark it "ready for committer"? How
>> did you
Bruce Momjian escribió:
> On Wed, Jun 26, 2013 at 03:22:06PM -0300, Rodrigo Gonzalez wrote:
> > Checking release notes for 9.2.4
> >
> > you have Fix insecure parsing of server command-line switches
> > (Mitsumasa Kondo, Kyotaro Horiguchi)
> >
> > What about (it people think that it is good) a s
On 26 June 2013 20:55, Josh Berkus wrote:
> On 06/26/2013 12:29 AM, Szymon Guz wrote:
> > OK, so I think this patch can be committed, I will change the status.
>
> Can we have a full review before you mark it "ready for committer"? How
> did you test it? What kinds of review have you done?
>
>
On 06/26/2013 12:29 AM, Szymon Guz wrote:
> OK, so I think this patch can be committed, I will change the status.
Can we have a full review before you mark it "ready for committer"? How
did you test it? What kinds of review have you done?
The committer can't know whether it's ready or not if he
On Thu, Jun 27, 2013 at 12:01 AM, Jeff Janes wrote:
> I don't think that sounds all that promising. When the hash table does not
> fit in memory, it is either partitioned into multiple passes, each of which
> do fit in memory, or it chooses a different plan altogether.
Yeah, my point is, we cou
On Wed, Jun 26, 2013 at 03:22:06PM -0300, Rodrigo Gonzalez wrote:
> On Wed, 26 Jun 2013 14:13:32 -0400
> > Production of the release notes was not the problem; it was the text
> > in the release notes. I don't see how we could modify the release
> > note format.
> >
>
> Well...
>
> Checking re
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
> I've been playing around with the idea of an aggregate that computes
> the sum of the md5 hashes of each of its inputs, which I've called
> md5_total() for now, although I'm not particularly wedded to that
> name. Comparing it with md5
On Wed, Jun 26, 2013 at 5:01 AM, Atri Sharma wrote:
>
> > The problem here is that if the hash table is in memory, doing a hash
> > table lookup directly is likely to be cheaper than a bloom filter
> > lookup, even if the bloom filter fits into the processor cache and the
> > hash table doesn't (
On Wed, 26 Jun 2013 14:13:32 -0400
Bruce Momjian wrote:
> On Wed, Jun 26, 2013 at 03:12:00PM -0300, Rodrigo Gonzalez wrote:
> > On Wed, 26 Jun 2013 09:14:07 -0400
> > Bruce Momjian wrote:
> >
> > > On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
> > > > On 26 June 2013 03:17, Josh
On Wed, Jun 26, 2013 at 11:14 AM, Bruce Momjian wrote:
> On Wed, Jun 26, 2013 at 05:10:00PM +0300, Heikki Linnakangas wrote:
>> In practice, there might be a lot of quirks and inefficiencies and
>> locking contention etc. involved in various DBMS's, that you might
>> be able to work around with ha
On Wed, Jun 26, 2013 at 03:12:00PM -0300, Rodrigo Gonzalez wrote:
> On Wed, 26 Jun 2013 09:14:07 -0400
> Bruce Momjian wrote:
>
> > On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
> > > On 26 June 2013 03:17, Josh Berkus wrote:
> > > > How should reviewers get credited in the relea
On Wed, 26 Jun 2013 09:14:07 -0400
Bruce Momjian wrote:
> On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
> > 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 "Reviewe
On 2013-06-26 12:07:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-17 16:16:22 +0200, Andres Freund wrote:
> >> Not accepting EWOULDBLOCK in the above if() results in:
> >> could not connect to server: Resource temporarily unavailable
> >> Is the server running locally and accept
On Wed, Jun 26, 2013 at 10:25 AM, Andrew Dunstan wrote:
>
> On 06/26/2013 09:14 AM, Bruce Momjian wrote:
>>
>> On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
>>>
>>> On 26 June 2013 03:17, Josh Berkus wrote:
How should reviewers get credited in the release notes?
>>>
Hello
updated patch with some basic doc
Regards
Pavel
2013/6/26 Rushabh Lathia :
>
>
>
> On Wed, Jun 26, 2013 at 5:11 PM, Pavel Stehule
> wrote:
>>
>> 2013/6/26 Rushabh Lathia :
>> >
>> >
>> >
>> > On Tue, Jun 25, 2013 at 11:09 AM, Pavel Stehule
>> >
>> > wrote:
>> >>
>> >> 2013/6/25 Rushabh
>
> Isn't it currently the last week of this month? :) I'm guessing you
> mean July.
Heh,no.I lose track of time these days. Alright, second week of July then.
> I really don't see that happening, to be honest.. I think it would be
> interesting to try some of the surrogate-additional-hashing
* Atri Sharma (atri.j...@gmail.com) wrote:
> Right, let me look.Although, I am pretty busy atm with ordered set
> functions, so will get it done maybe last week of this month.
Isn't it currently the last week of this month? :) I'm guessing you
mean July.
> Another thing I believe in is that we s
On Wed, Jun 26, 2013 at 8:57 PM, Amit Kapila wrote:
> On Wednesday, June 26, 2013 4:40 PM Andres Freund wrote:
>> Hi Amit,
>>
>> On 2013-06-26 16:22:28 +0530, Amit Kapila wrote:
>> > On Wednesday, June 26, 2013 1:20 PM Andres Freund wrote:
>> > > On 2013-06-26 08:50:27 +0530, Amit Kapila wrote:
>>
On Wed, Jun 26, 2013 at 2:36 PM, Hari Babu wrote:
> 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.
The following description in the document of pg_ctl needs to be modified?
restar
Andres Freund writes:
> I am generally a bit unsure whether the regression tests you propose
> aren't a bit too verbose. Does any of the committers have an opinion
> about this?
> My feeling is that they are ok if they aren't slowing down things much.
Yeah, I'm concerned about speed too. If the
Josh Berkus writes:
> Well, one of the other "prizes" which occurred to me today would be a
> pgCon lottery. That is, each review posted by a non-committer would go
> in a hat, and in February we would draw one who would get a free
> registration and airfare to pgCon.
+1, I like that idea!
Rega
On Thu, Jun 27, 2013 at 12:02 AM, Alvaro Herrera
wrote:
> Amit Langote escribió:
>
>> The segfault in question happens at line 1141:
>>
>> off = att_align_pointer(off, thisatt->attalign, -1, tp + off);
>>
>> char *tp; /* ptr to tuple data */
>> longoff;
Andres Freund writes:
> On 2013-06-17 16:16:22 +0200, Andres Freund wrote:
>> Not accepting EWOULDBLOCK in the above if() results in:
>> could not connect to server: Resource temporarily unavailable
>> Is the server running locally and accepting
>> connections on Unix domain socket "/tmp/.s.PGSQL.
On Wed, Jun 26, 2013 at 9:20 PM, Stephen Frost wrote:
> * Atri Sharma (atri.j...@gmail.com) wrote:
>> My point is that I would like to help in the implementation, if possible. :)
>
> Feel free to go ahead and implement it.. I'm not sure when I'll have a
> chance to (probably not in the next week
On 06/26/2013 05:46 PM, Heikki Linnakangas wrote:
> We could also allow a large query to search a single table in parallel.
> A seqscan would be easy to divide into N equally-sized parts that can be
> scanned in parallel. It's more difficult for index scans, but even then
> it might be possible at
On 24.06.2013 21:01, Andres Freund wrote:
Ok, I started to look at this:
Thanks!
* Could you document the way slots prevent checkpoints from occurring
when XLogInsert rechecks for full page writes? I think it's correct -
but not very obvious on a glance.
There's this in the comment ne
* Atri Sharma (atri.j...@gmail.com) wrote:
> My point is that I would like to help in the implementation, if possible. :)
Feel free to go ahead and implement it.. I'm not sure when I'll have a
chance to (probably not in the next week or two anyway). Unfortunately,
the bigger issue here is really
On 26.06.2013 18:34, Kevin Grittner wrote:
Markus Wanner wrote:
On 06/25/2013 11:52 PM, Kevin Grittner wrote:
At least until we have parallel
query execution. At *that* point this all changes.
Can you elaborate on that, please? I currently have a hard time
imagining how partitions can help
Markus Wanner wrote:
> On 06/25/2013 11:52 PM, Kevin Grittner wrote:
>> At least until we have parallel
>> query execution. At *that* point this all changes.
>
> Can you elaborate on that, please? I currently have a hard time
> imagining how partitions can help performance in that case,
> either.
On Mon, Jun 24, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> Thanks for your work, your patch is definitely better. I agree that this
> approach much more generic.
Committed.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
On 06/25/2013 08:26 PM, Andres Freund wrote:
> It's not about the reviewers being less. It's a comparison of
> effort. The effort for a casual review simply isn't comparable with the
> effort spent on developing a nontrivial patch.
Remember: "Debugging is twice as hard as writing the code in the f
On Wed, Jun 26, 2013 at 05:04:11PM +0200, Markus Wanner wrote:
> On 06/26/2013 04:01 PM, k...@rice.edu wrote:
> > I think he is referring to the fact that with parallel query execution,
> > multiple partitions can be processed simultaneously instead of serially
> > as they are now with the resultin
On 06/26/2013 04:01 PM, k...@rice.edu wrote:
> I think he is referring to the fact that with parallel query execution,
> multiple partitions can be processed simultaneously instead of serially
> as they are now with the resulting speed increase.
Processing simultaneously is the purpose of parallel
On 06/25/2013 11:29 AM, Cédric Villemain wrote:
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
Amit Langote escribió:
> The segfault in question happens at line 1141:
>
> off = att_align_pointer(off, thisatt->attalign, -1, tp + off);
>
> char *tp; /* ptr to tuple data */
> longoff;/* offset in tuple data */
>
> Disassembling seems
Antonin Houska writes:
> If the WHERE clause moves up, then the resulting plan might be less
> efficient than the one we'd get if the subquery hadn't been pulled-up at
> all.
No, because we can push the qual back down again (using a parameterized
path) if that's appropriate. The problem at thi
On 06/26/2013 04:10 PM, Yuri Levinsky wrote:
> You typically don't want to use b-tree index when yo select
> more when ~1-2% of your data.
Agreed. Indices on columns with very low selectivity don't perform well.
(Postgres knows that and uses a sequential scan based on selectivity
estimates. Being
On 06/26/2013 12:52 AM, Tom Lane wrote:
Instead of setting it aside, can we (mis)use placeholder var (PHV), to
ensure that the WHERE clause is evaluated below the OJ; instead of
combining it with the ON clause?
No, that doesn't help; it has to be part of the joinquals at the join
node, or you do
On Wed, Jun 26, 2013 at 7:12 PM, Stephen Frost wrote:
> Atri,
>
> * Atri Sharma (atri.j...@gmail.com) wrote:
>> I just popped in here on Simon's advice to put an idea I had about
>> optimizing hash joins on this thread.
>
> I'd encourage reading the thread a bit first, in the future.. :)
>
Yeah, I
Ants Aasma writes:
> On Wed, Jun 26, 2013 at 9:46 AM, Atri Sharma wrote:
>> I have been reading the current implementation of hash joins, and in
>> ExecScanHashBucket, which I understand is the actual lookup function,
>> we could potentially look at a bloom filter per bucket. Instead of
>> actual
Heikki Linnakangas writes:
> On 26.06.2013 11:17, Yuri Levinsky wrote:
>> When you dealing with company, which has
>> ~350.000.000 users, and you don't want to use key/value data stores: you
>> need hash partitioned tables and hash partitioned table clusters to
>> perform fast search and 4-6 table
Hackers,
at last developer meeting we missed Oleg Bartunov. So, it's not surprising
that photos is also missed.
I remember that somebody took photos, but unfortunately it appears that I
don't remember who.
My employer who sponsored my attendance in PGCon want to publish post about
it on the websit
Heiki,
This is most professional explanation that I ever seen. Let me please
disagree with a bottom line. It's heavily depends on amount of memory
and actual index sizes. I did a benchmark ~6 years ago and I won a glass
of beer. Anyway I am talking about hash partitioning as a feature and
my exam
On Wed, Jun 26, 2013 at 05:10:00PM +0300, Heikki Linnakangas wrote:
> In practice, there might be a lot of quirks and inefficiencies and
> locking contention etc. involved in various DBMS's, that you might
> be able to work around with hash partitioning. But from a
> theoretical point of view, ther
On 26.06.2013 16:41, Yuri Levinsky wrote:
Heikki,
As far as I understand the height of the btree will affect the number of
I/Os necessary. The height of the tree does not increase linearly with
the number of records.
The height of a b-tree is O(log n), where n is the number of records.
Informa
Markus,
It's no relation between partitions and raids despite they both
distribute data somehow. By the end of the day when you use the raid you
have one single device with some performance limitations. When you want
to improve your data access after that and not to work with huge indexes
that you
FYI I submitted a slightly modified patch since Amit's measurements that is
slightly faster.
On Jun 25, 2013, at 1:26 PM, Amit Kapila wrote:
> On Monday, June 24, 2013 8:20 PM Tom Lane wrote:
>> Amit Kapila writes:
>>> I will summarize the results, and if most of us feel that they are
>> not
On Wed, Jun 26, 2013 at 03:47:43PM +0200, Markus Wanner wrote:
> On 06/25/2013 11:52 PM, Kevin Grittner wrote:
> > At least until we have parallel
> > query execution. At *that* point this all changes.
>
> Can you elaborate on that, please? I currently have a hard time
> imagining how partitions
On 06/25/2013 11:52 PM, Kevin Grittner wrote:
> At least until we have parallel
> query execution. At *that* point this all changes.
Can you elaborate on that, please? I currently have a hard time
imagining how partitions can help performance in that case, either. At
least compared to modern RAID
Atri,
* Atri Sharma (atri.j...@gmail.com) wrote:
> I just popped in here on Simon's advice to put an idea I had about
> optimizing hash joins on this thread.
I'd encourage reading the thread a bit first, in the future.. :)
> Essentially, I was thinking of using bloom filters in the part where
>
On Tue, Jun 25, 2013 at 11:17:47PM -0400, Peter Eisentraut wrote:
> 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
Heikki,
As far as I understand the height of the btree will affect the number of
I/Os necessary. The height of the tree does not increase linearly with
the number of records. May be I wrong in terminology but when I am
trying to insert data into empty table the insertion time is increasing
when num
On Wednesday, June 26, 2013 2:15 AM Heikki Linnakangas wrote:
> 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 by
On 06/26/2013 09:14 AM, Bruce Momjian wrote:
On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
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
1 - 100 of 145 matches
Mail list logo
