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 obvi
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 th
On Fri, Nov 16, 2012 at 7:58 PM, Andres Freund wrote:
> 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.
>
> Its a mism
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 heap_(insert|updat
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 ka
On Saturday, November 17, 2012 3:35 AM Dimitri Fontaine wrote:
> Tom Lane 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 ALTER ALL SET.
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 format
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 usuall
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 fu
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 performa
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 updatin
On Nov 17, 2012, at 9:18, Michael Giannakopoulos 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 if it is possib
Peter Eisentraut 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 in a lot of places, and tha
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
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) unique
Michael Giannakopoulos 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 the relation [d
Josh Berkus 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 impression that we
- Цитат от 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 tryi
> > 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
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 though
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 t
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 incomp
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 f
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 fr
On Fri, Nov 16, 2012 at 2:53 AM, Peter Eisentraut 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
> settings fo
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), the
On Sat, Nov 17, 2012 at 10:25 PM, Amit Kapila 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 prevent us from
changing t
Jeff Davis 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.
Really? What abo
Fujii Masao 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 move all GUCs into
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 alway
On 16 November 2012 19:58, Jeff Davis 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 update. It was
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.
On Sat, 2012-11-17 at 16:53 -0500, Tom Lane wrote:
> Jeff Davis 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_
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 dat
On Fri, Nov 16, 2012 at 5:35 PM, Jeff Davis 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 HOT update?
35 matches
Mail list logo
