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?
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 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 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 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 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
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
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
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
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 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, 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
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 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
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: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
> > 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
- Цитат от 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
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 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
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
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
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 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
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 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
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 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
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 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 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 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 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 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 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
35 matches
Mail list logo
