On 6 June 2011 21:57, Kevin Grittner wrote:
> HuangQi wrote:
>
> >>> (gdb) b qp_add_paths_to_joinrel
> >>> Breakpoint 1 at 0x1a6744: file joinpath.c, line 67.
> >>> (gdb) attach 23903
>
> > If I enter c, gdb will directly finish executing this process and
> > current query will finish.
>
> Are y
On Jun 6, 2011, at 4:35 PM, Tom Lane wrote:
>> That sounds like a good idea.
>
> BTW, it struck me shortly after sending this that we'd already discussed
> the idea of a flag in pg_proc showing whether a function pays attention
> to collation. We could of course use that for this purpose.
Seems
Andrew Dunstan writes:
> On 06/06/2011 07:30 PM, Robert Creager wrote:
>> [4de65a8f.607a:3] LOG: statement: CREATE OR REPLACE FUNCTION bar() RETURNS
>> integer AS $$
>> #die 'BANG!'; # causes server process to exit(2)
>> # alternative - causes server process to exit(255)
>> spi_exec_query("inval
Excerpts from Robert Haas's message of mar jun 07 00:07:06 -0400 2011:
> Did you intentionally fail to copy the list?
No, I noticed after I sent it ...
> On Tue, Jun 7, 2011 at 12:03 AM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of lun jun 06 22:29:02 -0400 2011:
> >> On F
On Mon, Jun 6, 2011 at 2:49 PM, Josh Berkus wrote:
>
>> That's an improvement of about ~3.5x. According to the vmstat output,
>> when running without the patch, the CPU state was about 40% idle.
>> With the patch, it dropped down to around 6%.
>
> Wow! That's fantastic.
>
> Jignesh, are you in a
On Mon, Jun 6, 2011 at 9:48 PM, Josh Kupershmidt wrote:
> On Sun, Jun 5, 2011 at 8:16 PM, Gurjeet Singh
> wrote:
> > Attached an updated patch.
> >
> > If you find it ready for committer, please mark it so in the commitfest
> app.
>
> I can't find anything further to nitpick with this patch, and
On Sun, Jun 5, 2011 at 8:16 PM, Gurjeet Singh wrote:
> Attached an updated patch.
>
> If you find it ready for committer, please mark it so in the commitfest app.
I can't find anything further to nitpick with this patch, and have
marked it Ready For Committer in the CF. Thanks for your work on th
On 06/06/2011 07:30 PM, Robert Creager wrote:
[4de65a8f.607a:1] LOG: connection received: host=[local]
[4de65a8f.607a:2] LOG: connection authorized: user=Robert
database=pl_regression
[4de65a8f.607a:3] LOG: statement: CREATE OR REPLACE FUNCTION bar() RETURNS
integer AS $$
#die
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I see no reason to delay from a July release as has long been planned.
>
> What open items are genuine blockers?
>
> If we need deadlines anywhere its in beta and final release, otherwise
> we all just sit around shrugging and saying "another week I
On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
>> I've now spent enough time working on this issue now to be convinced
>> that the approach has merit, if we can work out the kinks. I'll start
>> with some performance
"David E. Wheeler" writes:
> On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
>> ... One bit of infrastructure that might be a good idea is
>> a flag to indicate whether an equality operator's behavior is
>> potentially collation-dependent, so that we could avoid taking
>> performance hits in the norm
Dave Page writes:
> On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
>> If we're going to start putting in changes like this, I'd suggest that
>> we try and target something like September for 9.1 to actually be
>> released. Playing with the lock management isn't something we want to
>> be d
Merlin Moncure writes:
> I vote for at minimum the type itself and ANYRANGE to be in core.
> From there you could make it like arrays where the range type is
> automatically generated for each POD type. I would consider that for
> sure on basis of simplicity in user-land unless all the extra type
Brar Piening writes:
> On Fri, 13 May 2011 23:34:05 +0200, Brar Piening wrote:
> [...]
>> I'd appreciate any reviews, tests or comments.
> As the current commitfest is getting more and more active recently i've
> rechecked my patch and updated it for code drift.
> No real changes.
> See http://w
Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
> I've now spent enough time working on this issue now to be convinced
> that the approach has merit, if we can work out the kinks. I'll start
> with some performance numbers.
I hereby recommend that people with patches such a
On Mon, Jun 6, 2011 at 8:02 AM, Heikki Linnakangas
wrote:
> On 06.06.2011 09:35, Jim Nasby wrote:
>>
>> I've had a related idea that I haven't looked into... if you're scanning a
>> relation (ie: index scan, seq scan) I've wondered if it would be more
>> efficient to deal with the entire page at o
On Fri, 13 May 2011 23:34:05 +0200, Brar Piening wrote:
[...]
I'd appreciate any reviews, tests or comments.
As the current commitfest is getting more and more active recently i've
rechecked my patch and updated it for code drift.
No real changes.
See http://www.piening.info/VS2010v7.patch
T
Excerpts from Dimitri Fontaine's message of lun jun 06 15:12:54 -0400 2011:
> So, to the question “do we want hard deadlines?” I think the answer is
> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
> the question “does this very change should be considered this late?” my
>
On Mon, Jun 6, 2011 at 6:05 PM, Simon Riggs wrote:
> On Mon, Jun 6, 2011 at 10:09 PM, Jeff Janes wrote:
>> On Mon, Jun 6, 2011 at 11:27 AM, Simon Riggs wrote:
>>>
>>> But that even assumes we write the unzeroed data at the end of the
>>> buffer. We don't. We only write data up to the end of the
On Mon, Jun 6, 2011 at 8:52 PM, Dave Page wrote:
> On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
>> * Dave Page (dp...@pgadmin.org) wrote:
>>> Much as I hate to say it (I too want to keep our schedule as
>>> predictable and organised as possible), I have to agree. Assuming the
>>> patch is
On Mon, Jun 6, 2011 at 10:09 PM, Jeff Janes wrote:
> On Mon, Jun 6, 2011 at 11:27 AM, Simon Riggs wrote:
>>
>> But that even assumes we write the unzeroed data at the end of the
>> buffer. We don't. We only write data up to the end of the WAL record
>> on the current page, unless we do a continua
Excerpts from Tom Lane's message of lun jun 06 12:49:46 -0400 2011:
> Robert Haas writes:
> > Instead of closing them immediately, how about flagging the FD and
> > closing all the flagged FDs at the end of each query, or something
> > like that?
>
> Hmm, there's already a mechanism for closing
Jeff Davis wrote:
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advanta
On Mon, Jun 6, 2011 at 11:27 AM, Simon Riggs wrote:
>
> But that even assumes we write the unzeroed data at the end of the
> buffer. We don't. We only write data up to the end of the WAL record
> on the current page, unless we do a continuation record,
I see no codepath in XLogWrite which writes
On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
> The most workable alternative that I can see is to lobotomize citext so
> that it always does lower-casing according to the database's "default"
> collation, which would allow us to pretend that its notion of equality
> is not collation-sensitive after
Stephen Frost wrote:
> if people really want this in, then we need to figure out what the
> new schedule is going to be.
I suggest June, 2012. That way we can get a whole bunch more really
cool patches in, and the users won't have to wait for 9.2 to get
them.
-Kevin
--
Sent via pgsql-hack
I've been looking into bug #6053, in which Regina Obe complains that
hash-based DISTINCT queries fail for type "citext". The cause is not
far to seek: the header comment for execGrouping.c states
* Note: we currently assume that equality and hashing functions are not
* collation-sensitive, so t
On Mon, Jun 6, 2011 at 3:59 PM, Christopher Browne wrote:
> On Mon, Jun 6, 2011 at 5:13 PM, Simon Riggs wrote:
>> The cost to us is a few days work and the benefit is a whole year's
>> worth of increased performance for our user base, which has a hardware
>> equivalent well into the millions of d
On Mon, Jun 6, 2011 at 5:13 PM, Simon Riggs wrote:
> The cost to us is a few days work and the benefit is a whole year's
> worth of increased performance for our user base, which has a hardware
> equivalent well into the millions of dollars.
I doubt that this is an accurate reflection of the cost
On Mon, Jun 6, 2011 at 2:49 PM, Josh Berkus wrote:
>
>> That's an improvement of about ~3.5x. According to the vmstat output,
>> when running without the patch, the CPU state was about 40% idle.
>> With the patch, it dropped down to around 6%.
>
> Wow! That's fantastic.
>
> Jignesh, are you in a
On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost wrote:
> * Dave Page (dp...@pgadmin.org) wrote:
>> Much as I hate to say it (I too want to keep our schedule as
>> predictable and organised as possible), I have to agree. Assuming the
>> patch is good, I think this is something we should push into 9.1
On 06/06/2011 03:24 PM, Dave Page wrote:
On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine wrote:
So, to the question “do we want hard deadlines?” I think the answer is
“no”, to “do we need hard deadlines?”, my answer is still “no”, and to
the question “does this very change should be consider
On 6/6/11 12:12 PM, Dimitri Fontaine wrote:
> So, to the question “do we want hard deadlines?” I think the answer is
> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
> the question “does this very change should be considered this late?” my
> answer is yes.
I could not disag
On Mon, Jun 6, 2011 at 8:40 PM, Stefan Kaltenbrunner
wrote:
> On 06/06/2011 09:24 PM, Dave Page wrote:
>> On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
>> wrote:
>>> So, to the question “do we want hard deadlines?” I think the answer is
>>> “no”, to “do we need hard deadlines?”, my answer is
* Dave Page (dp...@pgadmin.org) wrote:
> Much as I hate to say it (I too want to keep our schedule as
> predictable and organised as possible), I have to agree. Assuming the
> patch is good, I think this is something we should push into 9.1. It
> really could be a game changer.
So, with folks putt
On 06/06/2011 09:24 PM, Dave Page wrote:
> On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
> wrote:
>> So, to the question “do we want hard deadlines?” I think the answer is
>> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
>> the question “does this very change should be
On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine wrote:
> So, to the question “do we want hard deadlines?” I think the answer is
> “no”, to “do we need hard deadlines?”, my answer is still “no”, and to
> the question “does this very change should be considered this late?” my
> answer is yes.
>
> B
Stephen Frost writes:
> I don't like the idea of having a capability which is not utilized
> in core. We should make it so extensions can *also* have access to
> define their own, but we should have the basics covered in core.
Well if another part of core depends on the feature set, then of cour
On Mon, Jun 6, 2011 at 10:33 AM, Heikki Linnakangas
wrote:
> On 06.02.2011 23:09, Simon Riggs wrote:
>>
>> On Sun, 2011-02-06 at 12:11 -0500, Bruce Momjian wrote:
>>>
>>> Did this ever get addressed?
>>
>> Patch attached.
>>
>> Seems like the easiest fix I can come up with.
>
>> @@ -2518,7 +2518,7
Robert Haas writes:
> IMHO, it's better to just have a deadline,
Well, that's the fine point we're now talking about.
I still think that we should try at making the best release possible.
And if that means including changes at beta time because that's when
someone got around to doing them, so
> That's an improvement of about ~3.5x. According to the vmstat output,
> when running without the patch, the CPU state was about 40% idle.
> With the patch, it dropped down to around 6%.
Wow! That's fantastic.
Jignesh, are you in a position to test any of Robert's work using DBT or
other benc
On Mon, Jun 6, 2011 at 7:09 AM, Pavel Golub wrote:
> Sorry for delay in answer. Yeah, I'm glad to. Should I apply this
> patch by myself?
sure, run it against your test case and make sure it works. if so, we
can pass it up the chain of command (hopefully as context diff).
merlin
--
Sent via pg
On Sun, Jun 5, 2011 at 1:59 PM, Jeff Davis wrote:
> In the several talks that I've given, a common question is related to
> "multiranges" (ranges with holes). These get a little complex, and I
> don't have a complete answer. However, multiranges can be approximated
> with ordered arrays of non-ove
On Mon, Jun 6, 2011 at 5:47 PM, Tom Lane wrote:
> Simon Riggs writes:
>> In earlier discussions of how to improve WALInsertLock contention, it
>> was observed that we must zero each new page before we advance the WAL
>> insertion point.
>> http://postgresql.1045698.n5.nabble.com/Reworking-WAL-loc
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> That means that this is, IMHO, the right approach. Have core support
> that enables user defined RANGE types with indexing and planner support,
> etc, like we have OPERATOR CLASS and FAMILY and all the jazz.
Yes, we do, however..
> And the use
On Mon, Jun 6, 2011 at 2:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 6, 2011 at 1:03 PM, Alvaro Herrera
>> wrote:
>>> Hmm, if we're going to have pg_comments as a syntactic sugar kind of
>>> thing, it should output things in format immediately useful to the user,
>>> i.e. relatio
Robert Haas writes:
> On Mon, Jun 6, 2011 at 1:03 PM, Alvaro Herrera
> wrote:
>> Hmm, if we're going to have pg_comments as a syntactic sugar kind of
>> thing, it should output things in format immediately useful to the user,
>> i.e. relation/column/etc names and not OIDs. The OIDs would force y
The attached patch refactors heap_hot_search_buffer() so that
index_getnext() can use it, and modifies index_getnext() to do so.
The idea is based on one of Heikki's index-only scan patches, from 2009:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00676.php
I believe, however, that thi
On Mon, Jun 06, 2011 at 12:53:49PM -0400, Robert Haas wrote:
>
> I don't have clear feeling on this question in general, but if we're
> going to break this up into pieces, it's important that they be
> logical pieces. Putting half the feature in core and half into an
> extension just because we c
On Fri, Jun 03, 2011 at 09:51:45PM +0300, Peter Eisentraut wrote:
> The external PID file, if configured, is currently generated with 600
> permissions, which results from the umask setting in the postmaster. I
> think it would be nicer if we could make that 644.
>
> I have often dealt with scrip
I just started with some image as blob works. And I think topic of this will
come back. As well many other problems will arise. Flattering tuple, etc.
I will send scretches of streaming in this way, I hope, as I want go back to
clusterization work.
Sorry, for top reply, windows phone 7.
Regar
On Mon, Jun 6, 2011 at 1:03 PM, Alvaro Herrera
wrote:
> Excerpts from Josh Kupershmidt's message of dom jun 05 16:36:57 -0400 2011:
>> On Tue, May 24, 2011 at 10:31 PM, Josh Kupershmidt
>> wrote:
>> > Attached is a rebased patch. From a quick look, it seems that most of
>> > the object types mis
2011/6/6 Jeff Davis :
> On Mon, 2011-06-06 at 18:28 +0200, Pavel Stehule wrote:
>> we can define a step
>>
>> FOREACH x IN RANGE . BY
>
> That wouldn't need any of the range infrastructure at all -- it would be
> purely syntactic, right?
>
I don't think. For lot of types the specification
On Mon, Jun 6, 2011 at 5:14 PM, Kevin Grittner
wrote:
> Perhaps the best way to describe the suggestion that this be
> included in 9.1 isn't that it's an insane suggestion; but that it's
> a suggestion which, if adopted, would be likely to drive those who
> are striving for a more organized devel
Excerpts from Tom Lane's message of lun jun 06 12:49:46 -0400 2011:
> Robert Haas writes:
> > On Mon, Jun 6, 2011 at 12:30 PM, Tom Lane wrote:
> >> On reflection I think this behavior is probably limited to the case
> >> where we've done what we used to call a "blind write" of a block that
> >> i
Excerpts from Josh Kupershmidt's message of dom jun 05 16:36:57 -0400 2011:
> On Tue, May 24, 2011 at 10:31 PM, Josh Kupershmidt wrote:
> > Attached is a rebased patch. From a quick look, it seems that most of
> > the object types missing from \dd are already covered by pg_comments
> > (cast, cons
On Mon, Jun 6, 2011 at 12:49 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun jun 06 08:06:10 -0400 2011:
>
>> But the problem of vacuum stalling out because it can't get the
>> cleanup lock is a very real one. I've seen at least one customer hit
>> this in production, and i
On Sun, Jun 5, 2011 at 2:59 PM, Jeff Davis wrote:
> So, where on this spectrum should range types fall? I think the most
> minimalist would be to only support #1 (and the necessary type IO
> functions); and leave all other functions, operators, and opclasses to
> an extension. That has a lot of ap
On Mon, 2011-06-06 at 16:45 +, Christopher Browne wrote:
> How to slice it apart into an appropriate admixture of core and
> extensions is a good question, though it seems pretty likely that
> having an extension for each data type that is to be mixed into a
> range is a reasonable way to go.
Robert Haas writes:
> On Mon, Jun 6, 2011 at 12:30 PM, Tom Lane wrote:
>> On reflection I think this behavior is probably limited to the case
>> where we've done what we used to call a "blind write" of a block that
>> is unrelated to our database or tables. For normal SQL-driven accesses,
>> the
Excerpts from Robert Haas's message of lun jun 06 08:06:10 -0400 2011:
> But the problem of vacuum stalling out because it can't get the
> cleanup lock is a very real one. I've seen at least one customer hit
> this in production, and it was pretty painful. Now, granted, you need
> some bad appli
Simon Riggs writes:
> In earlier discussions of how to improve WALInsertLock contention, it
> was observed that we must zero each new page before we advance the WAL
> insertion point.
> http://postgresql.1045698.n5.nabble.com/Reworking-WAL-locking-td1983647.html
> IMHO the page zeroing is complet
On Mon, 2011-06-06 at 18:28 +0200, Pavel Stehule wrote:
> we can define a step
>
> FOREACH x IN RANGE . BY
That wouldn't need any of the range infrastructure at all -- it would be
purely syntactic, right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On Sun, Jun 5, 2011 at 6:59 PM, Jeff Davis wrote:
> There might also be some middle ground, where its like the minimalist
> approach, but with a few very basic constructors and accessors. That
> would at least make it easier to test, but then to be actually useful
> (with index support, operators,
On Mon, 2011-06-06 at 14:42 +0200, Dimitri Fontaine wrote:
> I think the way things are going to be organised now is that we will
> have core-blessed extensions: don't mix the mechanism and the policy.
I like that idea.
> > non-issue if we had a good type interface system (that works on
> > poly
On Mon, Jun 6, 2011 at 12:30 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of lun jun 06 12:10:24 -0400 2011:
>>> Yeah, I wasn't that thrilled with the suggestion either. But we can't
>>> just have backends constantly closing every open FD they hold, or
>>> per
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun jun 06 12:10:24 -0400 2011:
>> Yeah, I wasn't that thrilled with the suggestion either. But we can't
>> just have backends constantly closing every open FD they hold, or
>> performance will suffer. I don't see any very good place t
2011/6/6 Jeff Davis :
> On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote:
>> 2011/6/6 Darren Duncan :
>> > Jeff Davis wrote:
>> >>
>> >> I'd like to take another look at Range Types and whether part of it
>> >> should be an extension. Some of these issues relate to extensions in
>> >> general
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
> Jeff Davis wrote:
> > I'd like to take another look at Range Types and whether part of it
> > should be an extension. Some of these issues relate to extensions in
> > general, not just range types.
> >
> > First of all, what are the advanta
Alvaro Herrera wrote:
> That doesn't solve the WAL problem Kevin found, of course ...
I wouldn't worry about that too much -- the WAL issue is
self-limiting and not likely to ever cause a failure. The biggest
risk is that every now and then some new individual will notice it
and waste a bit o
On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote:
> 2011/6/6 Darren Duncan :
> > Jeff Davis wrote:
> >>
> >> I'd like to take another look at Range Types and whether part of it
> >> should be an extension. Some of these issues relate to extensions in
> >> general, not just range types.
> >>
>
Excerpts from Tom Lane's message of lun jun 06 12:10:24 -0400 2011:
> Alvaro Herrera writes:
> > Hmm interesting. I don't think the placement suggested by Tom would be
> > useful, because the Zabbix backends are particularly busy all the time,
> > so they wouldn't run ProcessCatchupEvent at all.
In earlier discussions of how to improve WALInsertLock contention, it
was observed that we must zero each new page before we advance the WAL
insertion point.
http://postgresql.1045698.n5.nabble.com/Reworking-WAL-locking-td1983647.html
IMHO the page zeroing is completely unnecessary, and replicatio
Robert Haas wrote:
> IMHO, it's better to just have a deadline, and stuff either makes
> it or it doesn't. I realize we haven't always adhered to the
> principle in the past, but at least IMV that's not a mistake we
> want to continue repeating.
+1
I've said it before, but I think it bears
Alvaro Herrera writes:
> Excerpts from Kevin Grittner's message of lun jun 06 11:58:51 -0400 2011:
>> Alvaro Herrera wrote:
>>> What we found out after more careful investigation is that the
>>> file is kept open by a backend connected to a different database.
>>> I have a suspicion that what ha
Excerpts from Kevin Grittner's message of lun jun 06 11:58:51 -0400 2011:
> Alvaro Herrera wrote:
>
> > What we found out after more careful investigation is that the
> > file is kept open by a backend connected to a different database.
> > I have a suspicion that what happened here is that thi
Alvaro Herrera wrote:
> What we found out after more careful investigation is that the
> file is kept open by a backend connected to a different database.
> I have a suspicion that what happened here is that this backend
> was forced to flush out a page from shared buffers to read some
> other
On 06.06.2011 16:58, Robert Haas wrote:
On Sun, Jun 5, 2011 at 11:26 AM, Cyan Ogilvie wrote:
This is my first patch, so I hope I've got the process right for submitting
patches.
You're doing great. I suspect we do want to either (1) reword what
you've done in English, rather than writing it
On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs wrote:
> My point was that we have in the past implemented performance changes
> to increase scalability at the last minute, and also that our personal
> risk perspectives are not always set in stone.
>
> Robert has highlighted the value of this change
First off, this is posted to the wrong list -- this list is for
discussion of development of the PostgreSQL product. There is a
list for performance questions where this belongs:
pgsql-performa...@postgresql.org. I'm moving this to the
performance list with a blind copy to the -hackers list so pe
On 06.06.2011 17:13, Tom Lane wrote:
=?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
I think more about this with contrast to sent references, but I still
have in my mind construct
Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
outdated we have BlueRay
conn.prepareState
Excerpts from Tom Lane's message of sáb jun 04 12:49:05 -0400 2011:
> Alvaro Herrera writes:
> > What surprises me is that the open references remain after a database
> > drop. Surely this means that no backends keep open file descriptors to
> > any table in that database, because there are no co
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Introducing streaming for TOAST is little useless, sorry just for cite from
> my, mentoined document:
> (This is generally about on demand stream of TOASTed value, in
> context of LOBs is acceptable, as long not transactional aware LOBs are
> accepta
Tom Lane Monday 06 of June 2011 16:13:26
> =?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> > I think more about this with contrast to sent references, but I still
> > have in my mind construct
> > Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
> > outdated we have BlueRay
> >
Peter Eisentraut writes:
> What you are looking for is the SQL feature called "distinct types".
> The makers of the SQL standard have sort of deprecated domains in favor
> of distinct types, because distinct types address your sort of use case
> better, and prescribing the behavior of domains beco
Hi,
I am using postgresql 8.4.6. I have made an index on my data-type that is
working fine. I mean output is coming properly.
When i execute the query first time, query takes a quite longer time but
second time execution of the same query takes very less time (despite
execution plan is same)
Thi
On Mon, Jun 6, 2011 at 11:19 AM, Heikki Linnakangas
wrote:
> On 06.06.2011 12:40, Simon Riggs wrote:
>>
>> On Sat, Jun 4, 2011 at 5:55 PM, Tom Lane wrote:
>>>
>>> Simon Riggs writes:
The approach looks sound to me. It's a fairly isolated patch and we
should be considering this for
=?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> I think more about this with contrast to sent references, but I still
> have in my mind construct
> Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
> outdated we have BlueRay
> conn.prepareStatemnt("INSERT INTO someonetubevideo
On Sun, Jun 5, 2011 at 11:26 AM, Cyan Ogilvie wrote:
> This is my first patch, so I hope I've got the process right for submitting
> patches.
You're doing great. I suspect we do want to either (1) reword what
you've done in English, rather than writing it as code, or at least
(2) add some SGML m
HuangQi wrote:
>>> (gdb) b qp_add_paths_to_joinrel
>>> Breakpoint 1 at 0x1a6744: file joinpath.c, line 67.
>>> (gdb) attach 23903
> If I enter c, gdb will directly finish executing this process and
> current query will finish.
Are you absolutely sure that running your query will result in a
On Mon, Jun 6, 2011 at 9:47 AM, HuangQi wrote:
> If I enter c, gdb will directly finish executing this process and current
> query will finish. Furthermore, if I enter next query, gdb will not debug it
> and stay in continue status.
Hmm, that must mean your breakpoint isn't properly set.
Instead
If I enter c, gdb will directly finish executing this process and current
query will finish. Furthermore, if I enter next query, gdb will not debug it
and stay in continue status.
On 6 June 2011 21:44, Robert Haas wrote:
> On Mon, Jun 6, 2011 at 3:43 AM, HuangQi wrote:
> > Hi,
> >I was usin
On Mon, Jun 6, 2011 at 3:43 AM, HuangQi wrote:
> Hi,
> I was using gdb to debug postgres. In order to debug the backend of
> running query, I start postgres first and use "select * from
> pg_backend_pid()" to ask for backend pid. Then I start gdb in another bash
> window with "gdb postgres" and
This patch enables to fix up leaky-view problem using functions with tiny cost
estimation scenario.
The point of this scenario is criteria to reorder qualifiers of scanning plan
in order_qual_clauses(). The optimizer may pull up simple subqueries into upper
level, then its qualifier will get me
On fre, 2011-06-03 at 13:53 -0500, Kevin Grittner wrote:
> Another long-range nicety would be something which I have seen in
> some other databases, and which is consistent with the inheritance
> theme, is that you can't compare or assign dissimilar domains -- an
> error is thrown. So if you try to
On tis, 2011-05-31 at 16:19 +0200, Florian Pflug wrote:
> If people deem this to be a problem, we could instead add a separate
> function XPATH_VALUE() that returns VARCHAR, and make people use that
> for scalar-value-returning expressions.
Why not replicate what contrib/xml2 provides, namely
xpa
Jeff Davis writes:
> I'd like to take another look at Range Types and whether part of it
> should be an extension. Some of these issues relate to extensions in
> general, not just range types.
That's a good question :)
I think the way things are going to be organised now is that we will
have cor
On 06.06.2011 14:59, Robert Haas wrote:
BTW, how do you identify from oprofile that *vxid* locks were the
problem? I didn't think it could produce that level of detail.
It can show the call stack of each call, with --callgraph=n option,
where you can see what percentage of the calls to LockAc
On Mon, Jun 6, 2011 at 4:14 PM, Alexander Korotkov wrote:
> If I succeed then it will invoke even more such calls.
>
I meant here that if I succeed in enhancements which improve index quality
then fast build algorithm will invoke even more such calls.
--
With best regards,
Alexander Korotkov.
On Mon, Jun 6, 2011 at 2:51 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Do you think there's some worst-case data distributions where this
> algorithm would perform particularly badly?
>
I think there could be some worst-case GiST applications. Just now gist fast
build a
1 - 100 of 121 matches
Mail list logo
