Simon Riggs writes:
> v3 attached
Thanks, will work on this tomorrow.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, 2010-04-25 at 13:51 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-04-25 at 13:33 -0400, Tom Lane wrote:
> >> If you like I'll have a go at rewriting the comments for this patch,
> >> because I am currently thinking that the problem is not so much with
> >> the code as with
Robert Haas writes:
> On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
>> There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
>> we still want to do that?
> I think you articulated some pretty good reasons previously for
> keeping it separate and, at any rate, I'm not e
On Mon, Apr 26, 2010 at 9:46 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
>> > There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
>> > we still want to do that?
>>
>> I think you articulated some pretty good reasons p
Robert Haas wrote:
> On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> > There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
> > we still want to do that?
>
> I think you articulated some pretty good reasons previously for
> keeping it separate and, at any rate, I'm not
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
> we still want to do that?
I think you articulated some pretty good reasons previously for
keeping it separate and, at any rate, I'm not eager to do it at the
11th hou
There was talk of including pg_migrator in Postgres 9.0 in /contrib. Do
we still want to do that?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Hello All:
The optimizer assumes that data is disk resident when computing the cost of a
query plan.
I am trying to ascertain what the correlation is between times and costs of
some benchmark queries to see how good the cost model is.
Since I have more than 100 queries, it would be painful to
Jaime Casanova writes:
> On Mon, Apr 26, 2010 at 3:03 PM, Robert Haas wrote:
>> On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
>> wrote:
>>> I would use EXPLAIN ANALYZE SELECT ...
>>
>> There's some overhead to that, of course.
> he could see the "actual time" in the very first row of the EXP
Robert Haas wrote:
> On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
> wrote:
>> "Murali M. Krishna" wrote:
>>
>>> Basically, I would like to discard the result rows after doing
>>> all the work required to execute the query.
>>
>> I would use EXPLAIN ANALYZE SELECT ...
>
> There's some overhea
Tom Lane escribió:
> [ forgot to respond to this part ]
>
> Robert Haas writes:
> > ... I don't see the problem with DROP.
> > Under the proposed design, it's approximately equivalent to dropping a
> > table that someone else has truncated. You just wait for the
> > necessary lock and then do i
On Mon, Apr 26, 2010 at 3:03 PM, Robert Haas wrote:
> On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
> wrote:
>> "Murali M. Krishna" wrote:
>>
>>> Basically, I would like to discard the result rows after doing all
>>> the work required to execute the query.
>>
>> I would use EXPLAIN ANALYZE SEL
Simon Riggs writes:
> On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote:
>> The current definition of Hot Standby is that it's a *read only*
>> behavior. Not read mostly. What you are proposing is a rather
>> fundamental change in the behavior of HS, and it doesn't seem to me
>> that it should b
On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner
wrote:
> "Murali M. Krishna" wrote:
>
>> Basically, I would like to discard the result rows after doing all
>> the work required to execute the query.
>
> I would use EXPLAIN ANALYZE SELECT ...
There's some overhead to that, of course.
Robert
On Mon, Apr 26, 2010 at 3:30 PM, Simon Riggs wrote:
> On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
>
>> And I don't
>> think you can even get that far, because I don't think too many people
>> here are going to say that we shouldn't add global temporary tables
>> unless we can also make t
On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
> >> And I don't
> >> think you can even get that far, because I don't think too many people
> >> here are going to say that we shouldn't add global temporary tables
>
On Mon, Apr 26, 2010 at 2:36 PM, Kevin Grittner
wrote:
> "Murali M. Krishna" wrote:
>
>> I looked at the documentation and I saw something about using the
>> keyword PERFORM rather than SELECT.
>
> I don't remember ever seeing anything like that. Do you have a URL?
>
i guess he is refering to t
Simon Riggs writes:
> On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
>> And I don't
>> think you can even get that far, because I don't think too many people
>> here are going to say that we shouldn't add global temporary tables
>> unless we can also make them work with Hot Standby.
> The
"Murali M. Krishna" wrote:
> Basically, I would like to discard the result rows after doing all
> the work required to execute the query.
I would use EXPLAIN ANALYZE SELECT ...
> I looked at the documentation and I saw something about using the
> keyword PERFORM rather than SELECT.
I don't
On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote:
> And I don't
> think you can even get that far, because I don't think too many people
> here are going to say that we shouldn't add global temporary tables
> unless we can also make them work with Hot Standby.
The policy round here for some t
On Mon, Apr 26, 2010 at 2:15 PM, Josh Berkus wrote:
> (a) is this checked in yet?
No.
> (b) should we delay Beta to test it?\
I suspect it's going to be checked in pretty soon, so that may not be
necessary. Not my call, though.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Folks,
(a) is this checked in yet?
(b) should we delay Beta to test it?\
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-
Hello Hackers:
Two questions.
1.
I would like to execute queries such as
select * from part and time the query. But I want to ignore how much time is
taken for printing the result to a file or the screen.
Basically, I would like to discard the result rows after doing all the work
required t
On Mon, April 26, 2010 09:43, Simon Riggs wrote:
> On Sun, 2010-04-25 at 23:52 +0200, Erik Rijkers wrote:
>
>> I'll try to repeat this pattern on other hardware; although
>> if my tests were run with faulty hardware I wouldn't know how/why
>> that would give the above effect (such a 'regular aberra
On Mon, April 26, 2010 08:52, Fujii Masao wrote:
> On Mon, Apr 26, 2010 at 3:25 AM, Erik Rijkers wrote:
>> FWIW, here are some more results from pgbench comparing
>> primary and standby (both with Simon's patch).
>
> Was there a difference in CPU utilization between the primary
> and standby?
>
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
>> Well, actually, now that I've looked at the patch I think it's starting
>> from a fundamentally wrong position anyway. Checkpoint records are a
>> completely wrong mechanism for transmitting this data to slaves, because
>> a
On Mon, Apr 26, 2010 at 10:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
>> wrote:
>>> * How about naming the parameter wal_level instead of wal_mode? That
>>> would better convey that the higher levels add stuff on top of the lower
>>> level
Robert Haas writes:
> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
> wrote:
>> * How about naming the parameter wal_level instead of wal_mode? That
>> would better convey that the higher levels add stuff on top of the lower
>> levels, instead of having different modes that are somehow mutu
Applied; catalog version bumped.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> > > Tom Lane wrote:
> > >> The current column ordering can be rationalized to some extent as
> > >>
> > >> 1. ide
Stephen Frost writes:
> Not to be a pain, but the hint really is kind of terrible.. It'd
> probably be better if you included somewhere that the insert appears to
> be a single column with a record-type rather than multiple columns of
> non-composite type..
I don't much care for the test, either
On 26 April 2010 11:19, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 11:27 PM, Rod Taylor wrote:
> > Is there any particular reason why the citext module doesn't have
> > citext_pattern_ops operator family?
>
> You forgot to send in the patch. :-)
>
> ...Robert
>
>
Yes, someone implementing thi
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Takahiro Itagaki wrote:
> >> Takahiro Itagaki wrote:
> >>
> >>> Revised patch attached. Please test it.
> >> I applied this version of the patch.
> >> Please check wheter the bug is fixed and any buildfarm failures.
> >
> > Great. I have merged in
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
> Simon Riggs writes:
>> No intention of doing that. This change allows people to see what the
>> dependency actually is once the bug has been fixed. Change needs to
>> start from here, not from where we were before.
>
> Well, actually, now that I'
* Robert Haas (robertmh...@gmail.com) wrote:
> > The first version is a lot more common and as it turns out, is sometimes
> > very hard to spot. This patch attaches a HINT message to these two
> > cases. The message itself could probably be a lot better, but I can't
> > think of anything.
> >
> >
On Mon, Apr 26, 2010 at 8:57 AM, Marko Tiikkaja
wrote:
> Hi,
>
> This came up on IRC today and I recall several instances of this during
> the last two months or so, so I decided to send a patch. The problem in
> question occurs when you have extra parentheses in an INSERT list:
>
> INSERT INTO f
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> Personally I agree with your objection to "crash" but not with the
>> objection to "standby". Maybe this would be appropriate:
>>
>> wal_mode = minimal | archive | hot_standby
>
> Ok, here's a patch implementing
Hi,
This came up on IRC today and I recall several instances of this during
the last two months or so, so I decided to send a patch. The problem in
question occurs when you have extra parentheses in an INSERT list:
INSERT INTO foo(a,b,c) SELECT (a,b,c) FROM ..; or
INSERT INTO foo(a,b,c) VALUES((
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane wrote:
Robert Haas writes:
Well, I think the real hole is that turning archive_mode=on results in
WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in principle you could have SR setups
that d
Tom Lane wrote:
> Personally I agree with your objection to "crash" but not with the
> objection to "standby". Maybe this would be appropriate:
>
> wal_mode = minimal | archive | hot_standby
Ok, here's a patch implementing this proposal. It adds a new wal_mode
setting, leaving archive_mode
On Wed, Apr 21, 2010 at 9:11 PM, Robert Haas wrote:
> On Wed, Apr 21, 2010 at 1:56 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ...shouldn't we move the "tests", plural, rather than just the one?
>>> It seems right to reject new SR connections during shutdown.
>>
>> Yeah; you'd also need to ad
On Mon, Apr 26, 2010 at 6:08 AM, Simon Riggs wrote:
> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
>> Tom Lane writes:
>> > The only workable
>> > alternative I can see to keeping archive_mode is to tell people to
>> > set archive_command to something like /usr/bin/true ... which
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I think the real hole is that turning archive_mode=on results in
>> WAL never being deleted unless it's successfully archived.
>
> Hm, good point. And at least in principle you could have SR setups
> that don't care
On Fri, Apr 23, 2010 at 11:27 PM, Rod Taylor wrote:
> Is there any particular reason why the citext module doesn't have
> citext_pattern_ops operator family?
You forgot to send in the patch. :-)
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Sun, Apr 25, 2010 at 10:19 PM, Jaime Casanova
wrote:
> On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas wrote:
>>
>> 1. We could move the responsibility for removing the files associated
>> with temp rels from the background writer to the owning backend. I
>> think the reason why we initially tru
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
> Tom Lane writes:
> > The only workable
> > alternative I can see to keeping archive_mode is to tell people to
> > set archive_command to something like /usr/bin/true ... which is not
> > simpler, especially not on Windows.
>
> Would i
Rod Taylor wrote:
> Is there any particular reason why the citext module doesn't have
> citext_pattern_ops operator family?
>
> Specifically, I wish to index for this type of query:
>
> ... WHERE citext_column LIKE 'Foo%';
I think it is a reasonable suggestion.
=# \d tbl
Table "public.t
Tom Lane writes:
> The only workable
> alternative I can see to keeping archive_mode is to tell people to
> set archive_command to something like /usr/bin/true ... which is not
> simpler, especially not on Windows.
Would it be possible to have "internal" commands there, as for example
cd is in
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
wrote:
>
> How many of the tests in the regular regression suite do anything useful
> when run against a standby server? They all have to set up a bunch of
> objects before they run queries, so you just get a lot of errors
> complaining that you
On Sun, 2010-04-25 at 23:52 +0200, Erik Rijkers wrote:
> I'll try to repeat this pattern on other hardware; although
> if my tests were run with faulty hardware I wouldn't know how/why
> that would give the above effect (such a 'regular aberration').
> testing is more difficult than I thought...
Jaime Casanova wrote:
> On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
> wrote:
>> 3) it should execute the existing set of tests (the ones installcheck
>> execute) but with a new set of expected results, that way we can be
>> sure that what should be disallowed is disallowed and that the
>> data
On Sun, 2010-04-25 at 19:18 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > [ v2 patch ]
>
> I've been studying this some more while making notes for improved
> comments, and I've about come to the conclusion that having readers
> move the tail pointer (at the end of KnownAssignedXidsGetAndSetXm
51 matches
Mail list logo
