On 11/16/2012 03:05 PM, Andres Freund wrote:
I'd like to provide a comparison of the proposed change set format to
the one used in Postgres-R.
Uh, sorry to interrupt you right here, but thats not the proposed
format ;)
Understood. Sorry, I didn't mean to imply that. It's pretty obvious to
On 11/16/2012 03:14 PM, Andres Freund wrote:
Whats the data type of the COID in -R?
It's short for CommitOrderId, a 32bit global transaction identifier,
being wrapped-around, very much like TransactionIds are. (In that sense,
it's global, but unique only for a certain amount of time).
In the
On Fri, Nov 16, 2012 at 7:58 PM, Andres Freund and...@2ndquadrant.comwrote:
Hi,
On 2012-11-16 13:44:45 +0900, Michael Paquier wrote:
This patch looks OK.
I got 3 comments:
1) Why changing the OID of pg_class_tblspc_relfilenode_index from 3171 to
3455? It does not look necessary.
On 2012-11-16 17:19:23 -0800, Jeff Davis wrote:
On Fri, 2012-11-16 at 16:09 +0100, Andres Freund wrote:
As far as I understand the code the crash-safety aspects of the
visibilitymap currently rely on on having the knowledge that ALL_VISIBLE
has been cleared during a
On Friday, November 16, 2012 7:52 PM Cédric Villemain wrote:
Le vendredi 16 novembre 2012 15:08:30, Amit Kapila a écrit :
On Thursday, November 15, 2012 8:18 PM Amit kapila wrote:
On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila
On Saturday, November 17, 2012 3:35 AM Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Have you considered ALTER SYSTEM SET ... ? We'd talked about that in
the context of the other patch, but it seems to fit much more
naturally
with this one. Or maybe ALTER GLOBAL SET or
On 11/16/2012 02:46 PM, Markus Wanner wrote:
Andres,
On 11/15/2012 01:27 AM, Andres Freund wrote:
In response to this you will soon find the 14 patches that currently
implement $subject.
Congratulations on that piece of work.
I'd like to provide a comparison of the proposed change set
On 11/17/2012 02:30 PM, Hannu Krosing wrote:
Is it possible to replicate UPDATEs and DELETEs without a primary key in
PostgreSQL-R
No. There must be some way to logically identify the tuple. Note,
though, that theoretically any (unconditional) unique key would suffice.
In practice, that usually
Hello guys,
My name is Michail Giannakopoulos and I am a graduate student at University
of Toronto. I have no previous experience in developing a system like
postgreSQL before.
What I am trying to explore is if it is possible to extend postgreSQL in
order to accept queries of the form:
Select
On 2012-11-16 22:31:51 -0500, Noah Misch wrote:
On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
Andres is on the verge of convincing me that we need to support
singleton FOR SHARE without multixacts due to performance
On 11/17/2012 03:00 PM, Markus Wanner wrote:
On 11/17/2012 02:30 PM, Hannu Krosing wrote:
Is it possible to replicate UPDATEs and DELETEs without a primary key in
PostgreSQL-R
No. There must be some way to logically identify the tuple.
It can be done as selecting on _all_ attributes and
On Nov 17, 2012, at 9:18, Michael Giannakopoulos miccagi...@gmail.com wrote:
Hello guys,
My name is Michail Giannakopoulos and I am a graduate student at University
of Toronto. I have no previous experience in developing a system like
postgreSQL before.
What I am trying to explore is
Peter Eisentraut pete...@gmx.net writes:
On Fri, 2012-09-28 at 11:10 -0500, Karl O. Pinc wrote:
pg_temp-toindex.patch
Puts pg_temp into the index of the docs.
But there is no object called pg_temp. It always pg_temp_
something. How should that be indexed?
We do replaceable/ in a
On Sat, Nov 17, 2012 at 03:20:20PM +0100, Andres Freund wrote:
On 2012-11-16 22:31:51 -0500, Noah Misch wrote:
On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
Andres is on the verge of convincing me that we need to
On 11/17/2012 03:00 PM, Markus Wanner wrote:
On 11/17/2012 02:30 PM, Hannu Krosing wrote:
Is it possible to replicate UPDATEs and DELETEs without a primary key in
PostgreSQL-R
No. There must be some way to logically identify the tuple. Note,
though, that theoretically any (unconditional)
Michael Giannakopoulos miccagi...@gmail.com writes:
What I am trying to explore is if it is possible to extend postgreSQL in
order to accept queries of the form:
Select function(att1, att2, att3) AS output(out1, out2, ..., outk) FROM
[database_name];
where att1, att2, att3 are attributes of
Josh Berkus j...@agliodbs.com writes:
You could make that same claim about plain views, but in point of
fact the demand for making them work in COPY has been minimal.
So I'm not convinced this is an essential first-cut feature.
We can always add it later.
Of course. I just had the
- Цитат от Michael Giannakopoulos (miccagi...@gmail.com), на 17.11.2012 в
16:18 -
Hello guys,
My name is Michail Giannakopoulos and I am a graduate student at University
of Toronto. I have no previous experience in developing a system like
postgreSQL before.
What I am trying to
I agree that tripling FOR SHARE cost is risky. Where is the added cost
concentrated? Perchance that multiple belies optimization opportunities.
Good question, let me play a bit.
Ok, I benchmarked around and from what I see there is no single easy
target.
The biggest culprits I could find
On 11/17/2012 12:19:02 AM, Peter Eisentraut wrote:
On Fri, 2012-09-28 at 11:10 -0500, Karl O. Pinc wrote:
pg_temp-toindex.patch
Puts pg_temp into the index of the docs.
But there is no object called pg_temp. It always pg_temp_
something. How should that be indexed?
My thought is
Hannu,
On 11/17/2012 03:40 PM, Hannu Krosing wrote:
On 11/17/2012 03:00 PM, Markus Wanner wrote:
On 11/17/2012 02:30 PM, Hannu Krosing wrote:
Is it possible to replicate UPDATEs and DELETEs without a primary key in
PostgreSQL-R
No. There must be some way to logically identify the tuple.
It
On 11/17/2012 12:27:14 AM, Peter Eisentraut wrote:
On Sun, 2012-09-23 at 21:22 -0500, Karl O. Pinc wrote:
Hi,
Adds a caution to the pg_restore docs
Against git master.
I'm not sure what you are trying to get at here. It's basically
saying,
if you make an incomplete database
CREATE TABLE foo (
x CHAR(32) PRIMARY KEY,
y CHAR(32) NOT NULL,
EXCLUDE USING gist ((ARRAY[x, y]) WITH )
);
ERROR: data type character[] has no default operator class for access method
gist
HINT: You must specify an operator class for the index or define a default
operator class for
On Sat, Nov 17, 2012 at 05:07:18PM +0100, Andres Freund wrote:
I agree that tripling FOR SHARE cost is risky. Where is the added cost
concentrated? Perchance that multiple belies optimization opportunities.
Good question, let me play a bit.
Ok, I benchmarked around and from what I
On Fri, Nov 16, 2012 at 2:53 AM, Peter Eisentraut pete...@gmx.net wrote:
Independent of the discussion of how to edit configuration files from
SQL, I had another idea how many of the use cases for this could be handled.
We already have the ability to store in pg_db_role_setting configuration
On Sat, 2012-11-17 at 14:24 +0100, Andres Freund wrote:
I think the point is that to check whether the visibilitymap bit needs
to be unset
What's the problem with that? If you already have the VM buffer pinned
(which should be possible if we keep the VM buffer in a longer-lived
structure), then
On Sat, Nov 17, 2012 at 10:25 PM, Amit Kapila amit.kap...@huawei.com wrote:
1. have a system table pg_global_system_settings(key,value)
Do we really need to store the settings in a system table?
Since WAL would be generated when storing the settings
in a system table, this approach seems to
Jeff Davis pg...@j-davis.com writes:
What's the problem with that? If you already have the VM buffer pinned
(which should be possible if we keep the VM buffer in a longer-lived
structure), then doing the test is almost as cheap as checking
PD_ALL_VISIBLE, because you don't need any locks.
Fujii Masao masao.fu...@gmail.com writes:
Do we really need to store the settings in a system table?
Since WAL would be generated when storing the settings
in a system table, this approach seems to prevent us from
changing the settings in the standby.
That's a really good point: if we try to
On Sat, 2012-11-17 at 11:33 -0600, Karl O. Pinc wrote:
On 11/17/2012 12:19:02 AM, Peter Eisentraut wrote:
On Fri, 2012-09-28 at 11:10 -0500, Karl O. Pinc wrote:
pg_temp-toindex.patch
Puts pg_temp into the index of the docs.
But there is no object called pg_temp. It always
On 16 November 2012 19:58, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2012-11-16 at 11:58 -0500, Robert Haas wrote:
Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced
in the visibility map patch, apparently as a way to know when to clear
the VM bit when doing an
On 11/17/2012 05:10:12 PM, Peter Eisentraut wrote:
On Sat, 2012-11-17 at 11:33 -0600, Karl O. Pinc wrote:
what's
indexed is the token pg_temp, used when
setting search_path.
Actually, since this is the pg_temp alias for the search path, it is
appropriate. So committed as is.
Thanks
On Sat, 2012-11-17 at 16:53 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
What's the problem with that? If you already have the VM buffer pinned
(which should be possible if we keep the VM buffer in a longer-lived
structure), then doing the test is almost as cheap as checking
On Sat, 2012-11-17 at 19:35 -0500, Simon Riggs wrote:
The biggest problem with hint bits is SeqScans on a table that ends up
dirtying many pages. Repeated checks against clog and hint bit setting
are massive overheads for the user that hits that, plus it generates
an unexpected surge of
On Fri, Nov 16, 2012 at 5:35 PM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2012-11-16 at 17:04 -0800, Jeff Janes wrote:
Your question prompts me to post something I had been wondering.
Might it be worthwhile to break the PD_ALL_VISIBLE / vm equivalence?
Should the vm bit get cleared by a
35 matches
Mail list logo
