On 04.12.2010 04:18, Tatsuo Ishii wrote:
There is a description about streaming replication in the doc:
--
25.2.5. Streaming Replication
:
:
If you set up a WAL archive that's accessible from the
standby, wal_keep_segments is not required a
On 04.12.2010 09:14, jes...@krogh.cc wrote:
There has been a lot discussion about index-only scans and how to make the
visibillity map crash safe. Then followed by a good discussion about hint bits.
What seems to be the main concern is the added wal volume and it makes me
wonder if there is a
There has been a lot discussion about index-only scans and how to make the
visibillity map crash safe. Then followed by a good discussion about hint bits.
What seems to be the main concern is the added wal volume and it makes me
wonder if there is a way in-between that looks more like hint bits.
"Ross J. Reedstrom" writes:
> If you consider that an index basically is, in some sense, a pre-canned
> column list, then:
> ALTER TABLE table_name ADD PRIMARY KEY (column_list);
> ALTER TABLE table_name ADD PRIMARY KEY USING index_name;
> are parallel constructions. And it avoids the error case
Robert Haas writes:
> 2010/9/13 Teodor Sigaev :
>> [updated patch]
> I realize I'm repeating myself, but... this patch needs
> documentation. It's not optional.
I've applied all of this, and written documentation for all of it,
except for the contrib/btree_gist additions which still need to be
While working on the KNNGIST documentation I noticed that it's possible
to create queries that will try to use a KNN scan as the inside of a
mergejoin, leading to a failure because GIST hasn't got mark/restore
support. For example, in the current HEAD regression database:
regression=# set enable_
On Dec 3, 2010, at 4:54 PM, Heikki Linnakangas
wrote:
> Here's an updated patch.
How carefully have you perf-tested this?
> On closer look, supporting the invalid tuples in scans was trivial, so I kept
> that after all. So you can still query an index with invalid tuples. If an
> insert encou
Hi all,
I have gone through the code a bit more this time and I think that what
I originally thought of as a task of executor in the beginning (as I
read the documentation) seems to be split at multiple points. So i am
asking a question based on what I have understood so far. Keeping it a
bit orga
On Wed, Dec 1, 2010 at 3:53 AM, Kristian Nielsen
wrote:
> Greg Stark writes:
>
>> Just so everyone is on the same page Even once we have index-only
>> scans they won't be anywhere near as useful with Postgres as they are
>> with Oracle and other databases. At least not unless we find a
>> sol
Hi,
There is a description about streaming replication in the doc:
--
25.2.5. Streaming Replication
:
:
If you set up a WAL archive that's accessible from the
standby, wal_keep_segments is not required as the standby can always
use the archi
Extensions Patch v15 Review
===
Submission review
-
* Is the patch in context diff format?
Yes.
* Does it apply cleanly to the current git master?
Yes.
* Does it include reasonable tests, necessary doc patches, etc?
`make check` passes.
`make installch
On Fri, Dec 3, 2010 at 18:02, Dimitri Fontaine wrote:
> Schema | Name | Result data type | Argument data types | Type
> +-+--+-+
> pg_catalog | replace | text | text, VARIADIC text | normal
> pg_catalog | replac
Heikki Linnakangas writes:
> On 03.12.2010 23:53, Oleg Bartunov wrote:
>> create table qq (b box);
>> CREATE TABLE
>> select count(*), b from qq group by b;
>> ERROR: could not identify an equality operator for type box
>> What does it means ?
> GROUP BY requires b-tree sort operators. Although t
On 12/3/10 2:16 PM, Robert Treat wrote:
> Uh, the syntax I posted was based on this currently valid syntax:
>
> ALTER TABLE table_name ADD PRIMARY KEY (column_list);
>
> The constraint bit is optional, which is why I left it out, but I
> presume it would be optional with the new syntax as well.
On Fri, Dec 03, 2010 at 05:16:04PM -0500, Robert Treat wrote:
> On Fri, Dec 3, 2010 at 4:41 PM, Josh Berkus wrote:
>
> > However, I don't see why we need (column_list). Surely the index has a
> > column list already?
> >
> > ALTER TABLE table_name ADD CONSTRAINT pk_name PRIMARY KEY USING index_na
On Fri, Dec 3, 2010 at 4:41 PM, Josh Berkus wrote:
> On 12/3/10 12:27 PM, Robert Haas wrote:
> > On Fri, Dec 3, 2010 at 2:56 PM, r t wrote:
> >> What exactly was the objection to the following -->
> >> ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
> >> Is the objection t
On 03.12.2010 23:53, Oleg Bartunov wrote:
create table qq (b box);
CREATE TABLE
select count(*), b from qq group by b;
ERROR: could not identify an equality operator for type box
LINE 1: select count(*), b from qq group by b;
but following select works fine
select ' (43.6038,48.8664536),(1.3620
Ok, casting to ::text solves the problem, but still I think we
need to fix it in the right way
Oleg
On Sat, 4 Dec 2010, Oleg Bartunov wrote:
Hi there,
create table qq (b box);
CREATE TABLE
select count(*), b from qq group by b;
ERROR: could not identify an equality operator for type box
LINE
Hi there,
create table qq (b box);
CREATE TABLE
select count(*), b from qq group by b;
ERROR: could not identify an equality operator for type box
LINE 1: select count(*), b from qq group by b;
but following select works fine
select ' (43.6038,48.8664536),(1.3620777,1.44327)'::box = '
(43.60
On 12/3/10 12:27 PM, Robert Haas wrote:
> On Fri, Dec 3, 2010 at 2:56 PM, r t wrote:
>> What exactly was the objection to the following -->
>> ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
>> Is the objection that you might have been trying to specify a constraint
>> named
On Fri, Dec 3, 2010 at 2:56 PM, r t wrote:
> What exactly was the objection to the following -->
> ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
> Is the objection that you might have been trying to specify a constraint
> named "using" ? I'm willing to make that option mor
All,
So, this week I've had my hands on a medium-high-end test system where I
could test various wal_sync_methods. This is a 24-core Intel Xeon
machine with 72GB of ram, and 8 internal 10K SAS disks attached to a
raid controller with 512MB BBU write cache. 2 of the disks are in a
RAID1, which su
On 03.12.2010 21:58, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of vie dic 03 16:45:59 -0300 2010:
ALTER TABLE table_name SET PRIMARY KEY USING INDEX index_name. Quite
verbose, but imho USING makes it much more clear that it's an existing
index.
I was going to post the s
On Fri, Dec 3, 2010 at 2:43 PM, Robert Haas wrote:
> On Fri, Dec 3, 2010 at 2:23 PM, Peter Eisentraut wrote:
> > On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
> >> On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
> >> wrote:
> >> > On Fri, Nov 26, 2010 at 05:58, Steve Singer
> wrote:
On 03.12.2010 21:55, Josh Berkus wrote:
All,
So, I've been doing some reading about this issue, and I think
regardless of what other changes we make we should never enable O_DIRECT
automatically on Linux, and it was a mistake for us to do so in the
first place.
First, in the Linux docs for open
Excerpts from Heikki Linnakangas's message of vie dic 03 16:45:59 -0300 2010:
> ALTER TABLE table_name SET PRIMARY KEY USING INDEX index_name. Quite
> verbose, but imho USING makes it much more clear that it's an existing
> index.
I was going to post the same thing (well except I was still thin
All,
So, I've been doing some reading about this issue, and I think
regardless of what other changes we make we should never enable O_DIRECT
automatically on Linux, and it was a mistake for us to do so in the
first place.
First, in the Linux docs for open():
=
In summary, O_DIRECT is a
On 03.12.2010 21:43, Robert Haas wrote:
On Fri, Dec 3, 2010 at 2:23 PM, Peter Eisentraut wrote:
On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
wrote:
On Fri, Nov 26, 2010 at 05:58, Steve Singer wrote:
The attached version of the pat
On 29.11.2010 08:10, Noah Misch wrote:
I have a hot_standby system and use it to bear the load of various reporting
queries that take 15-60 minutes each. In an effort to avoid long pauses in
recovery, I set a vacuum_defer_cleanup_age constituting roughly three hours of
the master's transactions.
On Fri, Dec 3, 2010 at 2:23 PM, Peter Eisentraut wrote:
> On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
>> On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
>> wrote:
>> > On Fri, Nov 26, 2010 at 05:58, Steve Singer
>> > wrote:
>> >> The attached version of the patch gets your regressio
On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
> On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
> wrote:
> > On Fri, Nov 26, 2010 at 05:58, Steve Singer wrote:
> >> The attached version of the patch gets your regression tests to pass.
> >> I'm going to mark this as ready for a committer
On Thu, 2010-12-02 at 19:00 -0500, Robert Haas wrote:
> Untidy buffers would be treated as dirty by the background writer
> cleaning scan, but as clean by checkpoints and by backends doing
> emergency buffer cleaning to feed new allocations.
Differentiating between a backend write and a bgwriter
On Dec 3, 2010, at 8:38 AM, Dimitri Fontaine wrote:
> David, and anyone feeling like reviewing or trying the patch, if you're
> not already crawling into the v14 patch, you could as well begin with
> this cleaner version — no behavior changes, some cleaner code, make
> check passes, no bitrot agai
On 12/03/2010 06:43 PM, Heikki Linnakangas wrote:
On 03.12.2010 13:49, flyusa2010 fly wrote:
When writing log, dbms should synchronously flush log to disk. I'm
wondering, if it is possible that the logs are in disk cache, while the
control is returned to dbms again, so dbms thinks logs are persi
On 03.12.2010 13:49, flyusa2010 fly wrote:
When writing log, dbms should synchronously flush log to disk. I'm
wondering, if it is possible that the logs are in disk cache, while the
control is returned to dbms again, so dbms thinks logs are persistent on
disk. In this case, if the disk fails, the
On 12/03/2010 12:17 PM, Alvaro Herrera wrote:
Excerpts from Robert Haas's message of vie dic 03 13:56:32 -0300 2010:
I know the use cases are limited, but I think it's still useful on its own.
I don't understand what's so difficult about starting with the snapshot
cloning patch. AFAIR it's
* Tom Lane:
> $ git push
> Counting objects: 172, done.
> Compressing objects: 100% (89/89), done.
> Writing objects: 100% (89/89), 17.07 KiB, done.
> Total 89 (delta 80), reused 0 (delta 0)
> To ssh://g...@gitmaster.postgresql.org/postgresql.git
>35a3def..8a6eb2e REL8_1_STABLE -> REL8_1_S
When writing log, dbms should synchronously flush log to disk. I'm
wondering, if it is possible that the logs are in disk cache, while the
control is returned to dbms again, so dbms thinks logs are persistent on
disk. In this case, if the disk fails, then there's incorrectness for dbms
log writing,
Indeed, hypothetical indexes are good to check potentially good
configurations without harming the whole system with actual index
creation. Please observer that we've added an "explain hypothetical"
command, that will include plans considering hypothetical indexes! We'll
try to add a simple cas
Excerpts from Robert Haas's message of vie dic 03 13:56:32 -0300 2010:
> I know the use cases are limited, but I think it's still useful on its own.
I don't understand what's so difficult about starting with the snapshot
cloning patch. AFAIR it's already been written anyway, no?
--
Álvaro Herr
On Fri, Dec 3, 2010 at 11:40 AM, Andrew Dunstan wrote:
>
>
> On 12/03/2010 11:23 AM, Robert Haas wrote:
>>
>> On Fri, Dec 3, 2010 at 8:02 AM, Andrew Dunstan
>> wrote:
>>>
>>> I think Josh Berkus' comments in the thread you mentioned are correct:
>>>
Actually, I'd say that there's a broad set
On 12/03/2010 11:23 AM, Robert Haas wrote:
On Fri, Dec 3, 2010 at 8:02 AM, Andrew Dunstan wrote:
I think Josh Berkus' comments in the thread you mentioned are correct:
Actually, I'd say that there's a broad set of cases of people who want
to do a parallel pg_dump while their system is activ
Of course, there is a much more serious problem with the whole idea. I
have worked through most of the necessary changes and I'm now down to
changing heap_udate to comply with the new locking protocol.
The problem I'm now facing is that we need to know the set of updated
columns pretty early -- j
On Fri, Dec 3, 2010 at 8:02 AM, Andrew Dunstan wrote:
> I think Josh Berkus' comments in the thread you mentioned are correct:
>
>> Actually, I'd say that there's a broad set of cases of people who want
>> to do a parallel pg_dump while their system is active. Parallel pg_dump
>> on a stopped sys
On Thu, Dec 2, 2010 at 7:00 PM, Robert Haas wrote:
> But
> maybe we could ameliorate that problem by freezing more aggressively.
I realized as I was falling asleep last night any sort of more
aggressive freezing is going to be a huge bummer for Hot Standby
users, for which freezing generates a co
On Tue, Nov 30, 2010 at 1:48 PM, Tom Lane wrote:
> On the whole I agree with Robert --- let's just adjust the
> documentation, and not enlarge privileges in a way we might regret
> later.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
* Robert Haas:
> Those hint bit tests are a single machine instruction. It's tough
> to beat that. It's tough to get within two orders of magnitude.
> I'd like to, but I don't see how.
For some scans, it might be possible to hoist the checks out of inner
loops. (At least in principle, I'm not
Jeroen,
We add a simple case study (sourceforge page):
http://sourceforge.net/projects/hypotheticalind/files/TUTORIAL_8_4.pdf/download
Although this tutorial is for version 8.4, it also applies to other
versions.
Att,
Ana Carolina
2010/12/3 Jeroen Vermeulen
> On 2010-12-03 19:44, Sergio Lifsc
Robert Haas writes:
> I have committed the cfparser patch to which the above comments refer.
Excellent, thank you! On to merging that into the extension's main
branch, will still wait until after pg_execute_sql_file() is in to
produce extension.v15.patch, unless advised otherwise.
Regards,
--
D
On Thu, Nov 25, 2010 at 4:06 PM, Dimitri Fontaine
wrote:
> Itagaki Takahiro writes:
>> Thanks. I'll move the patch to Ready for Committer.
>
> Thanks!
I have committed the cfparser patch to which the above comments refer.
One patch per thread makes things easier!
I adopted most of Itagaki Taka
On 2010-12-03 19:44, Sergio Lifschitz wrote:
Indeed, hypothetical indexes are good to check potentially good
configurations without harming the whole system with actual index
creation. Please observer that we've added an "explain hypothetical"
command, that will include plans considering hypothet
On 12/02/2010 11:44 PM, Joachim Wieland wrote:
On Thu, Dec 2, 2010 at 9:33 PM, Tom Lane wrote:
In particular, this issue *has* been discussed before, and there was a
consensus that preserving dump consistency was a requirement. I don't
think that Joachim gets to bypass that decision just by
* Tom Lane:
> Yeah. You certainly don't want to do the division sequence twice,
> and a log() call wouldn't be cheap either, and there don't seem to
> be many other alternatives.
What about a sequence of comparisons, and unrolling the loop? That
could avoid the final division, too. It might al
On Dec 3, 2010, at 2:17 AM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of jue dic 02 21:10:48 -0300 2010:
>> On Thu, Dec 2, 2010 at 3:43 PM, Alvaro Herrera
>> wrote:
>>> Excerpts from Robert Haas's message of jue dic 02 17:27:01 -0300 2010:
>
>>> Yeah, the Oracle system is a lo
On Thu, Dec 2, 2010 at 10:53 PM, Alvaro Herrera
wrote:
> Excerpts from Andy Colson's message of vie dic 03 00:37:17 -0300 2010:
>
>> Ok, forget the time thing. Has nothing to do with it. (Which everyone
>> already assumed I imagine).
>>
>> Its truncate.
>>
>> Create unloged table, fill it, trun
On Thu, Dec 2, 2010 at 9:33 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Umm, nobody has attributed ridiculousness to anyone. Please don't put
>> words in my mouth. But I think this is a perfectly reasonable discussion
>> to have. Nobody gets to come along and get the features they want
>> wit
On 03/12/10 08:14, Jeroen Vermeulen wrote:
On 2010-12-02 00:48, Ana Carolina Brito de Almeida wrote:
We would like to inform you all that our extension to PostgreSQL, that
includes hypothetical indexes (and soon index self-tuning), is
available through a sourgeforge project.
Looking at the s
On 02.12.2010 23:12, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of jue dic 02 16:52:27 -0300 2010:
Ok, committed, with some small cleanup since the last patch I posted.
I think the comments on _ReadBuf and friends need to be updated, since
they are not just for headers an
Itagaki Takahiro writes:
> I fixed and cleanup some of codes in it; v9 patch attached. Please check
> my modifications, and set the status to "Ready to Committer" if you find
> no problems. I think documentation and code comments might need to be
> checked by native English speakers.
Many thanks,
Itagaki Takahiro writes:
> Dimitri, your name cannot be added in source files,
> but will be recorded in commit logs ;-)
Oh, I've only been adding it to src/backend/utils/adt/genfile.c because
I saw another name in there. So of course a stricter following of the
project's copyright and naming her
On 03.12.2010 03:55, Fujii Masao wrote:
On Thu, Dec 2, 2010 at 12:16 AM, Euler Taveira de Oliveira
wrote:
As you said, there are platforms that a signal doesn't wake up a
process, so I suggest (ii) but I'm fine to include (i) at docs too.
Can we use "pg_ctl kill" to send signal on such platf
On 2010-12-02 00:48, Ana Carolina Brito de Almeida wrote:
We would like to inform you all that our extension to PostgreSQL, that includes
hypothetical indexes (and soon index self-tuning), is available through a
sourgeforge project.
This was suggested at PgCon 2010 and we hope some of you may
62 matches
Mail list logo
