On Mon, 11 Oct 2010 13:22:13 -0400
Robert Haas wrote:
> On Thu, Oct 7, 2010 at 7:20 AM, Shigeru HANADA
> wrote:
> > In this step, optimizer calls FdwRoutine->GetStatistics() to get
> > estimated costs of the foreign scan. ?FDW can calculate costs by
> > itself with some statistics, or get costs f
2010/10/12 Pavel Stehule :
> Hello
>
> 2010/10/11 Greg Stark :
>> On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
>>> It was pointed out upthread that while median isn't presently
>>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>>> which *is* in the standard.
>>
>> Uhmm, t
(2010/10/12 11:35), Robert Haas wrote:
> On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei wrote:
>> It seems to me the conclusion of this discussion is unclear.
>>
>> We commonly try to find out an approach that minimize code complexity
>> to understand and maintain, so the point of issue is clear, b
On Mon, Oct 11, 2010 at 10:17 PM, Gurjeet Singh wrote:
>> > Yes. I had the idea of trying to fix this by allowing the standby to
>> > retain old versions of entire pages that got cleaned up on the master,
>> > until the transactions that might want to read the old pages were
>> > gone. But that
On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei wrote:
> It seems to me the conclusion of this discussion is unclear.
>
> We commonly try to find out an approach that minimize code complexity
> to understand and maintain, so the point of issue is clear, but we
> still don't reach same conclusion, be
On Mon, Oct 11, 2010 at 7:16 PM, Jeff Davis wrote:
> On Mon, 2010-10-11 at 16:07 -0400, Robert Haas wrote:
> > >> It would be far better if we could decouple master cleanup from
> > >> standby cleanup, so that only the machine that actually has the old
> > >> query gets bloated. However, no one
It seems to me the conclusion of this discussion is unclear.
We commonly try to find out an approach that minimize code complexity
to understand and maintain, so the point of issue is clear, but we
still don't reach same conclusion, because both of two ideas have merits
and demerits each other.
On Mon, Oct 11, 2010 at 9:44 PM, Greg Stark wrote:
> On Mon, Oct 11, 2010 at 5:41 PM, Robert Haas wrote:
>> That's probably not going to happen until we have a way to update
>> postgresql.conf via SQL. Which, I maintain, as I have maintained
>> before, is not going to happen until we get rid of
On Mon, Oct 11, 2010 at 5:41 PM, Robert Haas wrote:
> That's probably not going to happen until we have a way to update
> postgresql.conf via SQL. Which, I maintain, as I have maintained
> before, is not going to happen until we get rid of the comments,
> because otherwise absolutely any implemen
On Mon, Oct 11, 2010 at 9:29 PM, Josh Berkus wrote:
What is your source for those numbers? They could be right, but I
simply don't know.
>>> pg_bench tests with asynch rep and standby_delay = 0. Not rigorous, but
>>> enough to show that there is a problem there. Doing pg_bench with a
> That's probably not going to happen until we have a way to update
> postgresql.conf via SQL. Which, I maintain, as I have maintained
> before, is not going to happen until we get rid of the comments,
> because otherwise absolutely any implementation anyone proposes will
> get criticized for fai
On Sun, 10 Oct 2010, Marko Tiikkaja wrote:
On 2010-10-07 5:21 AM +0300, Steve Singer wrote:
Since no one else has proposed a better idea and the commit fest is ticking
away I think you should go ahead and do that.
Here's a new version of the patch, deprecating pg_parse_and_rewrite.
I duplica
(2010/10/12 3:34), Peter Eisentraut wrote:
> On tor, 2010-10-07 at 12:45 +0900, KaiGai Kohei wrote:
>> * The logic is still unclear for me.
>>
>> The check_hostname() immediately returns with false, if the resolved
>> remote hostname is NOT matched with the hostname described in pg_hba.conf.
>
>>
On Mon, Oct 11, 2010 at 7:16 PM, Jeff Davis wrote:
> On Mon, 2010-10-11 at 16:07 -0400, Robert Haas wrote:
>> > I was initially taken aback by the word "useless" as well. However, I
>> > had trouble thinking of a use case that isn't better solved by sync rep
>> > without HS, or async rep. I don't
On Mon, Oct 11, 2010 at 5:40 PM, Josh Berkus wrote:
>> Obviously. I presume it'll be something like "update postgresql.conf
>> or recovery.conf and run pg_ctl reload", but I haven't (yet, anyway)
>> verified the actual behavior of the patches, but if the above isn't
>> feasible then we have a pro
On Mon, 2010-10-11 at 16:07 -0400, Robert Haas wrote:
> > I was initially taken aback by the word "useless" as well. However, I
> > had trouble thinking of a use case that isn't better solved by sync rep
> > without HS, or async rep. I don't have the numbers either though, so
> > perhaps someone do
> Obviously. I presume it'll be something like "update postgresql.conf
> or recovery.conf and run pg_ctl reload", but I haven't (yet, anyway)
> verified the actual behavior of the patches, but if the above isn't
> feasible then we have a problem.
Right. That's why I asked the question. Mind yo
On Mon, Oct 11, 2010 at 4:01 PM, Jeff Davis wrote:
> On Mon, 2010-10-11 at 15:22 -0400, Robert Haas wrote:
>> >> This is a completely separate issue from making replication
>> >> synchronous. And, really? Useless for running read queries?
>> >
>> > Absolutely. For a synch standby, you can't tol
On Mon, 2010-10-11 at 15:22 -0400, Robert Haas wrote:
> >> This is a completely separate issue from making replication
> >> synchronous. And, really? Useless for running read queries?
> >
> > Absolutely. For a synch standby, you can't tolerate any standby delay
> > at all. This means that anywh
On Mon, Oct 11, 2010 at 2:07 PM, Josh Berkus wrote:
>> I'll take a crack at answering these. I don't think that the
>> procedure for setting up a standby server is going to change much.
>> The idea is presumably that you set up an async standby more or less
>> as you do now and then make whatever
Hello
2010/10/11 Greg Stark :
> On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
>> It was pointed out upthread that while median isn't presently
>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>> which *is* in the standard.
>
> Uhmm, then why don't we implement that? We co
On tor, 2010-10-07 at 12:45 +0900, KaiGai Kohei wrote:
> * The logic is still unclear for me.
>
> The check_hostname() immediately returns with false, if the resolved
> remote hostname is NOT matched with the hostname described in pg_hba.conf.
> If the resolved hostname is matched with the hostna
> Uhmm, then why don't we implement that? We could provide median() as a
> short-cut but percentile_cont() doesn't sound much harder to implement
> than median() and more general.
I could really use percentile_cont(0.9), actually, for query
response-time analysis.
--
On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane wrote:
> It was pointed out upthread that while median isn't presently
> in the standard, Oracle defines it in terms of percentile_cont(0.5)
> which *is* in the standard.
Uhmm, then why don't we implement that? We could provide median() as a
short-cut but
On 11 October 2010 19:05, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 October 2010 18:48, Tom Lane wrote:
>>> And? If the memory requirement actually fits, you're in good shape.
>
>> Yeah but the actual memory requirement, if it uses a hash aggregate,
>> is over 1GB, and could easily be muc
On Mon, Oct 11, 2010 at 04:14:04PM +0530, Vaibhav Kaushal wrote:
> Is there something like that in Kdevelop? I dont use CLI editors much.
KDevelop is listed as one of the editors that support ctags.
http://en.wikipedia.org/wiki/Ctags
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1
Robert,
> I'll take a crack at answering these. I don't think that the
> procedure for setting up a standby server is going to change much.
> The idea is presumably that you set up an async standby more or less
> as you do now and then make whatever configuration changes are
> necessary to flip i
Dean Rasheed writes:
> On 11 October 2010 18:48, Tom Lane wrote:
>> And? If the memory requirement actually fits, you're in good shape.
> Yeah but the actual memory requirement, if it uses a hash aggregate,
> is over 1GB, and could easily be much higher.
In that case the estimate of 30K per in
On 11 October 2010 18:48, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 October 2010 18:37, Tom Lane wrote:
>>> Sure it would: an estimate of 30K would keep the planner from using
>>> hash aggregation.
>
>> Not if work_mem was 10MB.
>
> And? If the memory requirement actually fits, you're in
Dean Rasheed writes:
> On 11 October 2010 18:37, Tom Lane wrote:
>> Sure it would: an estimate of 30K would keep the planner from using
>> hash aggregation.
> Not if work_mem was 10MB.
And? If the memory requirement actually fits, you're in good shape.
regards, tom lan
On Thu, Oct 7, 2010 at 2:05 PM, Josh Berkus wrote:
> What is the procedure for adding a new synchronous standby in your
> implementation? That is, how do we go from having a standby server with
> an empty PGDATA to having a working synchronous standby?
I'll take a crack at answering these. I do
On 11 October 2010 18:37, Tom Lane wrote:
> Dean Rasheed writes:
>> The estimate of 200 x 8K is below work_mem, so it uses a hash
>> aggregate. In reality, each tuplesort allocates around 30K initially,
>> so it very quickly uses over 1GB. A better estimate for the aggregate
>> wouldn't improve t
Dean Rasheed writes:
> The estimate of 200 x 8K is below work_mem, so it uses a hash
> aggregate. In reality, each tuplesort allocates around 30K initially,
> so it very quickly uses over 1GB. A better estimate for the aggregate
> wouldn't improve this situation much.
Sure it would: an estimate o
On 11 October 2010 16:44, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 October 2010 15:03, Tom Lane wrote:
>>> Reflecting on it, I think it'd be best to allow an agg to
>>> provide an estimation function that'd be told the input data type and
>>> expected number of rows --- even on a per-aggr
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> On Sun, 2010-09-19 at 17:36 -0400, Tom Lane wrote:
>>> While building 3rd party RPMs using PGXS, even if I specify docdir in
>>> Makefile, README.* files are installed to this directory, which breaks
>>> parallel installation path as of 9.0+
>> Maybe y
On Thu, Oct 7, 2010 at 7:20 AM, Shigeru HANADA
wrote:
> [ design for FDW ]
This seems mostly sensible.
> In this step, optimizer calls FdwRoutine->GetStatistics() to get
> estimated costs of the foreign scan. FDW can calculate costs by
> itself with some statistics, or get costs from remote-sid
Robert Haas writes:
> On Mon, Oct 11, 2010 at 10:14 AM, Tom Lane wrote:
>> Reduction of contention for pg_clog access, for one thing. If you read
>> the archives, you'll find that pg_clog access contention has been shown
>> to be one cause of "context swap storms".
> I wonder if we could improv
Dean Rasheed writes:
> On 11 October 2010 15:03, Tom Lane wrote:
>> Reflecting on it, I think it'd be best to allow an agg to
>> provide an estimation function that'd be told the input data type and
>> expected number of rows --- even on a per-aggregate basis, a constant
>> estimate just isn't go
On 11 October 2010 15:03, Tom Lane wrote:
> Dean Rasheed writes:
>> On 10 October 2010 22:16, Tom Lane wrote:
>>> BTW, as far as the implementation issues go, telling tuplesort that it
>>> can use gigabytes of memory no matter what seems quite unacceptable.
>>> Put this thing into a hash aggrega
> I wonder if we could improve this with some sort of process-local
> cache - not to get rid of hint bits, just to reduce pg_clog
> contention. We might easily end up testing the same XID many times
> during the same table scan.
I guess that's my scenario... not that many transactions, so ev
On Mon, Oct 11, 2010 at 10:14 AM, Tom Lane wrote:
> Reduction of contention for pg_clog access, for one thing. If you read
> the archives, you'll find that pg_clog access contention has been shown
> to be one cause of "context swap storms".
I wonder if we could improve this with some sort of pro
> Reduction of contention for pg_clog access, for one thing. If you read
> the archives, you'll find that pg_clog access contention has been shown
> to be one cause of "context swap storms". Having to go to clog for
> every single tuple access would make that orders of magnitude worse.
Ok;
Magnus Hagander writes:
> On Mon, Oct 11, 2010 at 16:17, Tom Lane wrote:
>> ... and, if you are seriously expecting to have that happen, why the
>> patch was submitted to pgsql-jdbc not pgsql-hackers?
> To be fair to David, it was sent to *both* pgsql-jdbc and
> pgsql-hackers. Maybe it was held
On Mon, Oct 11, 2010 at 10:08 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Oct 10, 2010 at 5:16 PM, Tom Lane wrote:
>>> It was pointed out upthread that while median isn't presently
>>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>>> which *is* in the standard. W
On Mon, Oct 11, 2010 at 16:17, Tom Lane wrote:
> "Kevin Grittner" writes:
>> David Fetter wrote:
>>> Please find enclosed a WIP patch from one of my co-workers
>>> intended to support JDBC's setQueryTimeout, along with the patch
>>> for JDBC that uses it.
>
>> I agree that it would be very nice
"Kevin Grittner" writes:
> David Fetter wrote:
>> Please find enclosed a WIP patch from one of my co-workers
>> intended to support JDBC's setQueryTimeout, along with the patch
>> for JDBC that uses it.
> I agree that it would be very nice to support this JDBC feature, but
> I'm not clear on wh
Leonardo Francalanci writes:
> I was wondering what is the advantage of having hint bits for OLAP
> -style workloads, that is when the number of transactions is not
> that high.
> If I got it right, in 10 pg_clog pages we can store the status for more
> than 32 transactions. That's a lot, in
Robert Haas writes:
> On Sun, Oct 10, 2010 at 5:16 PM, Tom Lane wrote:
>> It was pointed out upthread that while median isn't presently
>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>> which *is* in the standard. What I read in SQL:2008 is that
>> percentile_cont is defi
Dean Rasheed writes:
> On 10 October 2010 22:16, Tom Lane wrote:
>> BTW, as far as the implementation issues go, telling tuplesort that it
>> can use gigabytes of memory no matter what seems quite unacceptable.
>> Put this thing into a hash aggregation and you'll blow out your memory
>> in no tim
David Fetter wrote:
> Please find enclosed a WIP patch from one of my co-workers
> intended to support JDBC's setQueryTimeout, along with the patch
> for JDBC that uses it.
I agree that it would be very nice to support this JDBC feature, but
I'm not clear on why this can't be done with just JD
Hi,
I was wondering what is the advantage of having hint bits for OLAP
-style workloads, that is when the number of transactions is not
that high.
If I got it right, in 10 pg_clog pages we can store the status for more
than 32 transactions. That's a lot, in a very small space
(80KB?).
So I
Greg,
to me it looks like we have very similar goals, but start from different
preconditions. I absolutely agree with you given the preconditions you
named.
On 10/08/2010 10:04 PM, Greg Smith wrote:
> How is that a new problem? It's already possible to end up with a
> standby pair that has suffe
On Sun, 2010-09-19 at 17:36 -0400, Tom Lane wrote:
> > While building 3rd party RPMs using PGXS, even if I specify docdir
> in
> > Makefile, README.* files are installed to this directory, which
> breaks
> > parallel installation path as of 9.0+
>
> Maybe you need to fool with MODULEDIR. See
> ht
Is there something like that in Kdevelop? I dont use CLI editors much.
On Mon, Oct 11, 2010 at 7:55 AM, David Christensen wrote:
>
> On Oct 10, 2010, at 12:21 PM, Vaibhav Kaushal wrote:
>
> > Thanks to both hitoshi and tom for your replies.
> >
> > I think I need to look into the Postgres code it
On Sat, Oct 9, 2010 at 3:33 AM, Simon Riggs wrote:
> On Fri, 2010-10-08 at 12:23 -0400, Robert Haas wrote:
>
>> It seems like it would be more helpful if you were working on
>> implementing a design that had more than one vote. As far as I can
>> tell, we have rough consensus that for the first c
On Sun, Oct 10, 2010 at 5:16 PM, Tom Lane wrote:
> It was pointed out upthread that while median isn't presently
> in the standard, Oracle defines it in terms of percentile_cont(0.5)
> which *is* in the standard. What I read in SQL:2008 is that
> percentile_cont is defined for all numeric types (
On 11 October 2010 10:55, Pavel Stehule wrote:
>> BTW, why has percentile been removed from this patch? As the more
>> general, and SQL standard function, that would seem to be the more
>> useful one to include. Upthread it was mentioned that there is already
>> an ntile window function, but actua
2010/10/11 Dean Rasheed :
> On 10 October 2010 22:16, Tom Lane wrote:
>> It was pointed out upthread that while median isn't presently
>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>> which *is* in the standard. What I read in SQL:2008 is that
>> percentile_cont is define
On 10 October 2010 22:16, Tom Lane wrote:
> It was pointed out upthread that while median isn't presently
> in the standard, Oracle defines it in terms of percentile_cont(0.5)
> which *is* in the standard. What I read in SQL:2008 is that
> percentile_cont is defined for all numeric types (returni
On 10 October 2010 19:06, Tom Lane wrote:
> Applied with revisions.
Brilliant! Thank you very much.
> * I took out this change in planmain.c:
>
> + /*
> + * If the query target is a VIEW, it won't be in the jointree, but we
> + * need a dummy RelOptInfo node for it. This need
* James Cloos:
> I'm reading this a bit late, but...
>
> We (Xorg) found that ignoring:
>
>*~
>*.bak
>*.patch
>
> in addition to the files generated by building is very helpful.
I tend to put those into .git/info/exclude. They are somewhat
developer-specific, after all.
--
Florian
Tom Lane writes:
> Might have something to do with using the same OID for the catalog
> and its index ...
Ahah, that's how obvious it was, thank you. I feel ashamed, but at the
same time, thanks to your answer, it now feels like the week-end was a
good preparatory step for opening this week.
Bac
2010/10/10 Tom Lane :
> Dean Rasheed writes:
>> In the meantime, the attached variation of the patch fixes the temp
>> file issue and will support all 3 cases. It gives OK performance for
>> (1) and (2), and poor performance for (3). That could be viewed as a
>> future development task, which perh
63 matches
Mail list logo
