On Wed, Jan 11, 2012 at 5:25 PM, Chetan Suttraway <
chetan.suttra...@enterprisedb.com> wrote:
>
>
> On Wed, Jan 11, 2012 at 5:13 PM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
>
>> Hi,
>> After running regression, I ran EXPLAIN on one of the queries in
>> regression (test create_mi
On Thu, Jan 12, 2012 at 12:20 AM, Simon Riggs wrote:
>> +static void
>> +ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime)
>>
>> walEnd is not used in ProcessWalSndrMessage() at all. Can't we remove it?
>> If yes, walEnd field in WalSndrMessage is also not used anywhere, so ISTM
>> we
On 01/11/2012 07:57 PM, Andrew Hammond wrote:
I'm working on a tool that runs pg_restore with -j 4. I notice that
after COPYing in the data, pg_restore does two indexes and a cluster
command in parallel. The first CREATE INDEX is running, the CLUSTER
command is waiting on it and the second CREA
On 12 January 2012 01:48, Robert Haas wrote:
> I've had cause, a few times this development cycle, to want to measure
> the amount of spinning on each lwlock in the system. To that end,
> I've found the attached patch useful. Note that if you don't define
> LWLOCK_STATS, this changes nothing exc
I've had cause, a few times this development cycle, to want to measure
the amount of spinning on each lwlock in the system. To that end,
I've found the attached patch useful. Note that if you don't define
LWLOCK_STATS, this changes nothing except that the return value from
s_lock becomes int rath
On Wed, Jan 11, 2012 at 7:09 PM, Tom Lane wrote:
> The question is how you prevent torn pages when a slave server crashes
> during replay. Right now, the presence of FPIs in the WAL stream,
> together with the requirement that replay restart from a checkpoint,
> is sufficient to guarantee that a
Thomas Munro writes:
> Here is an unfinished patch to implement something which appears on
> the TODO list under ALTER: automatic renaming of sequences created
> with serial when the table and column names change. I've often wanted
> this feature and it seemed like a good starter project.
Hmm ..
I'm working on a tool that runs pg_restore with -j 4. I notice that
after COPYing in the data, pg_restore does two indexes and a cluster
command in parallel. The first CREATE INDEX is running, the CLUSTER
command is waiting on it and the second CREATE INDEX is waiting on the
CLUSTER. This seems sub
On 01/11/2012 10:21 AM, Pavel Stehule wrote:
2012/1/11 Robert Haas:
On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule wrote:
I understand it now. My opinion is so some operators and index search
can be in 9.2 - so use a JSON just as communication format now.
* we need to build JSON
* we need t
"Kevin Grittner" writes:
> Going back through the patches we had to make to 9.0 to move to
> PostgreSQL triggers, I noticed that I let the issues raised as bug
> #6123 lie untouched during the 9.2 development cycle. In my view,
> the best suggestion for a solution was proposed by Florian here:
Hi,
Here is an unfinished patch to implement something which appears on
the TODO list under ALTER: automatic renaming of sequences created
with serial when the table and column names change. I've often wanted
this feature and it seemed like a good starter project. I'd be
grateful for any feedbac
Simon Riggs writes:
> On Wed, Jan 11, 2012 at 11:07 PM, Josh Berkus wrote:
>> On 1/11/12 1:25 PM, Dan Scales wrote:
>>> And just wanted to reiterate one other benefit of double writes -- it
>>> greatly reduces the size of the WAL logs.
>> Even if you're replicating?
> Yes, but it will increase
On 11 January 2012 23:51, Josh Berkus wrote:
>
>> Yeah, upthread Simon pointed out that propagating notifies would be
>> useful for flushing caches in applications that watch the database in a
>> read-only fashion. I grant that such a use-case is technically possible
>> within the limitations of
> Yeah, upthread Simon pointed out that propagating notifies would be
> useful for flushing caches in applications that watch the database in a
> read-only fashion. I grant that such a use-case is technically possible
> within the limitations of a slave server; I'm just dubious that it's a
> suff
Josh Berkus writes:
>> BTW ... it occurs to me to ask whether we really have a solid use-case
>> for having listeners attached to slave servers. I have personally never
>> seen an application for LISTEN/NOTIFY in which the listeners were
>> entirely read-only. Even if there are one or two cases
Going back through the patches we had to make to 9.0 to move to
PostgreSQL triggers, I noticed that I let the issues raised as bug
#6123 lie untouched during the 9.2 development cycle. In my view,
the best suggestion for a solution was proposed by Florian here:
http://archives.postgresql.org/pgs
On Jan 10, 2012, at 3:16 AM, Simon Riggs wrote:
> On Tue, Jan 10, 2012 at 12:24 AM, Jim Nasby wrote:
>> IIRC, pg_bench is *extremely* write-heavy. There's probably not that many
>> systems that operate that way. I suspect that most OLTP systems read more
>> than they write, and some probably hav
On Wed, Jan 11, 2012 at 11:07 PM, Josh Berkus wrote:
> On 1/11/12 1:25 PM, Dan Scales wrote:
>> And just wanted to reiterate one other benefit of double writes -- it
>> greatly reduces the size of the WAL logs.
>
> Even if you're replicating?
Yes, but it will increase random I/O on the standby w
PGCon 2012 will be held 17-18 May 2012, in Ottawa at the University of
Ottawa. It will be preceded by two days of tutorials on 15-16 May 2012.
We are now accepting proposals for talks. Proposals can be quite
simple. We do not require academic-style papers.
If you are doing something interestin
On 1/11/12 1:25 PM, Dan Scales wrote:
> And just wanted to reiterate one other benefit of double writes -- it greatly
> reduces the size of the WAL logs.
Even if you're replicating?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On 11/01/12 22:52, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
>> .colnames() returns a list of column names (strings)
>> .coltypes() returns a list of type OIDs (integers)
>>
>> I just made that up because there is no guidance in the other standard
>> PLs for this sort of thing, AFAICT.
>
On Sun, Jan 8, 2012 at 2:03 PM, Simon Riggs wrote:
> On Sat, Jan 7, 2012 at 11:09 AM, Simon Riggs wrote:
>> On Sat, Jan 7, 2012 at 10:55 AM, Simon Riggs wrote:
>>
>>> So there isn't any problem with there being incorrect checksums on
>>> blocks and you can turn the parameter on and off as often
On Wed, Jan 11, 2012 at 22:31, Jaime Casanova wrote:
> Hi,
>
> I just notice $SUBJECT and this could lead us to a segmentation fault
> if by accident we point to a system with a different number of columns
> in IDENTIFY_SYSTEM, at least i point pg_receivexlog from current head
> to a 9.0 instalati
Peter Eisentraut writes:
> .colnames() returns a list of column names (strings)
> .coltypes() returns a list of type OIDs (integers)
>
> I just made that up because there is no guidance in the other standard
> PLs for this sort of thing, AFAICT.
What about having the same or comparable API as in
Hi,
I just notice $SUBJECT and this could lead us to a segmentation fault
if by accident we point to a system with a different number of columns
in IDENTIFY_SYSTEM, at least i point pg_receivexlog from current head
to a 9.0 instalation and got that.
Any reason for not checking number of columns?
Thanks for all the comments and suggestions on the double-write patch. We are
working on generating performance results for the 9.2 patch, but there is
enough difference between 9.0 and 9.2 that it will take some time.
One thing in 9.2 that may be causing problems with the current patch is the
Here is a patch to add a command
ALTER TABLE ... RENAME CONSTRAINT ...
Currently, it only supports table constraints. I have an almost
finished patch for renaming domain constraints, but it is easier to keep
it separate.
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_tab
2012/1/11 Peter Eisentraut :
> In psql, the tab completion always converts key words to upper case. In
> practice, I and I think most users type in lower case. So then you end
> up with commands looking like this:
>
> => alter TABLE foo add CONSTRAINT bar check (a > 0);
>
> To address this, I hav
In psql, the tab completion always converts key words to upper case. In
practice, I and I think most users type in lower case. So then you end
up with commands looking like this:
=> alter TABLE foo add CONSTRAINT bar check (a > 0);
To address this, I have implemented a slightly different comple
Excerpts from Peter Eisentraut's message of mié ene 11 17:05:34 -0300 2012:
> There is currently no reliable way to retrieve from a result object in
> PL/Python the number, name, or type of the result columns. You can get
> the number and name if the query returned more than zero rows by looking
There is currently no reliable way to retrieve from a result object in
PL/Python the number, name, or type of the result columns. You can get
the number and name if the query returned more than zero rows by looking
at the row dicts, but that is unreliable. The type information isn't
available at
Tom,
> BTW ... it occurs to me to ask whether we really have a solid use-case
> for having listeners attached to slave servers. I have personally never
> seen an application for LISTEN/NOTIFY in which the listeners were
> entirely read-only. Even if there are one or two cases out there, it's
> n
"
I am able to write array_to_json fce and Andrew can write query_to_json"
+1
Thanks guys...
We are using a lot of JSON as communication protocol...
having core support for JSON, And those functions, will be a real life
saver...
Many thanks,
Misa
Sent from my Windows Phone
From: Pavel Stehul
2012/1/11 Robert Haas :
> On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule
> wrote:
>> I understand it now. My opinion is so some operators and index search
>> can be in 9.2 - so use a JSON just as communication format now.
>>
>> * we need to build JSON
>> * we need to check if some is valid JSON
>
On Wed, Jan 11, 2012 at 2:05 PM, Fujii Masao wrote:
> On Sat, Dec 31, 2011 at 10:34 PM, Simon Riggs wrote:
>> Send new protocol keepalive messages to standby servers.
>> Allows streaming replication users to calculate transfer latency
>> and apply delay via internal functions. No external functio
On Wed, Jan 11, 2012 at 9:47 AM, Aidan Van Dyk wrote:
> It does this by moving the FPW/IO penalty from the commit time of a
> backend dirtying the buffer first, to the eviction time of a backend
> evicting a dirty buffer. And if you're lucky enough that the
> background writer is the only one wri
On Wed, Jan 11, 2012 at 9:41 AM, Pavel Stehule wrote:
> I understand it now. My opinion is so some operators and index search
> can be in 9.2 - so use a JSON just as communication format now.
>
> * we need to build JSON
> * we need to check if some is valid JSON
> * we need to store JSON
>
> other
On Wed, Jan 11, 2012 at 7:13 AM, Heikki Linnakangas
wrote:
> At the moment, double-writes are done in one batch, fsyncing the
> double-write area first and the data files immediately after that. That's
> probably beneficial if you have a BBU, and/or a fairly large shared_buffers
> setting, so tha
2012/1/11 Robert Haas :
> On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule
> wrote:
>> I don't understand why we have to do it?
>>
>> We don't support similar functionality for XML, so why for JSON?
>
> Hrm. Well, that's an interesting point. Maybe we don't. I assumed
> that people would eventua
On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu wrote:
> However, I'm a bit afraid that it will confuse DBA if we use
> "restored" under the pg_xlog replay context, because we have
> already used "restored" that means a WAL file as successfully
> "copied" (not "replayed") from archive directory
On Wednesday, January 11, 2012 03:20:09 PM Greg Smith wrote:
> On 1/11/12 7:46 AM, Andres Freund wrote:
> > I played around with this before and my problem was that sync_file_range
> > is not really a hint. It actually starts writeback *directly* and only
> > returns when the io is placed inside th
On 1/11/12 7:46 AM, Andres Freund wrote:
I played around with this before and my problem was that sync_file_range is not
really a hint. It actually starts writeback *directly* and only returns when
the io is placed inside the queue (at least thats the way it was back then).
Which very quickly lea
On 1/11/12 4:33 AM, Florian Weimer wrote:
Isn't this pretty much like tuning vm.dirty_bytes? We generally set it
to pretty low values, and seems to help to smoothen the checkpoints.
When I experimented with dropping the actual size of the cache,
checkpoint spikes improved, but things like VAC
On Sat, Dec 31, 2011 at 10:34 PM, Simon Riggs wrote:
> Send new protocol keepalive messages to standby servers.
> Allows streaming replication users to calculate transfer latency
> and apply delay via internal functions. No external functions yet.
pq_flush_if_writable() needs to be called just af
On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule wrote:
> I don't understand why we have to do it?
>
> We don't support similar functionality for XML, so why for JSON?
Hrm. Well, that's an interesting point. Maybe we don't. I assumed
that people would eventually want to optimize queries of the f
2012/01/11 19:56, Simon Riggs wrote:
2012/1/11 Euler Taveira de Oliveira:
On 08-01-2012 11:59, Satoshi Nagayasu / Uptime Technologies, LLC. wrote:
[2011-12-08 15:14:36 JST] 16758: LOG: restored log file
"00080046" from archive
[2011-12-08 15:14:36 JST] 16758: LOG: recoverying
On Tue, Jan 10, 2012 at 11:38 PM, Greg Smith wrote:
> What you're doing here doesn't care though, and I hadn't considered that
> SYNC_FILE_RANGE_WRITE could be used that way on my last pass through its
> docs. Used this way, it's basically fsync without the wait or guarantee; it
> just tries to p
2012/1/11 Robert Haas :
> On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule
> wrote:
>> 2012/1/11 Robert Haas :
>>> On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler
>>> wrote:
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
> Are people explicitly asking for a) *JSON* datatype or b)
On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule wrote:
> 2012/1/11 Robert Haas :
>> On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler
>> wrote:
>>> On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
Are people explicitly asking for a) *JSON* datatype or b) a type that lets
you store
2012/1/11 Andrew Dunstan :
>
>
> On 01/11/2012 01:18 AM, Pavel Stehule wrote:
>>
>>
>> I like this patch and this feature.
>
>
> I'm about to read the patch in detail - I certainly like the feature.
>
>
>>
>> I see only one issue - there is not functionality that helps generate
>> JSON in pg.
>>
>>
On 01/11/2012 01:18 AM, Pavel Stehule wrote:
I like this patch and this feature.
I'm about to read the patch in detail - I certainly like the feature.
I see only one issue - there is not functionality that helps generate
JSON in pg.
What do you think about functions: array_to_json(anyarr
On Wednesday, January 11, 2012 10:33:47 AM Florian Weimer wrote:
> * Greg Smith:
> > One idea I was thinking about here was building a little hash table
> > inside of the fsync absorb code, tracking how many absorb operations
> > have happened for whatever the most popular relation files are. The
On Wednesday, January 11, 2012 10:28:11 AM Simon Riggs wrote:
> On Wed, Jan 11, 2012 at 4:38 AM, Greg Smith wrote:
> > On 1/10/12 9:14 PM, Robert Haas wrote:
> >> Based on that, I whipped up the attached patch, which,
> >> if sync_file_range is available, simply iterates through everything
> >> th
On Wednesday, January 11, 2012 03:14:31 AM Robert Haas wrote:
> Greg Smith muttered a while ago about wanting to do something with
> sync_file_range to improve checkpoint behavior on Linux. I thought he
> was talking about trying to sync only the range of blocks known to be
> dirty, which didn't s
On Wed, Jan 11, 2012 at 9:28 AM, Simon Riggs wrote:
> It does open the door to various other uses, so I think this work will
> be useful.
Yes, I think this would allow a better design for the checkpointer.
Checkpoint scan will collect buffers to write for checkpoint and sort
them by fileid, lik
On Wed, Jan 11, 2012 at 12:13 PM, Heikki Linnakangas
wrote:
> At the moment, double-writes are done in one batch, fsyncing the
> double-write area first and the data files immediately after that. That's
> probably beneficial if you have a BBU, and/or a fairly large shared_buffers
> setting, so th
On 10.01.2012 23:43, David Fetter wrote:
Please find attached a new revision of the double-write patch. While
this one still uses the checksums from VMware, it's been
forward-ported to 9.2.
I'd like to hold off on merging Simon's checksum patch into this one
for now because there may be some in
On Wed, Jan 11, 2012 at 5:13 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi,
> After running regression, I ran EXPLAIN on one of the queries in
> regression (test create_misc) and got following output
> regression=# explain verbose select * into table ramp from road where name
>
Hi,
After running regression, I ran EXPLAIN on one of the queries in regression
(test create_misc) and got following output
regression=# explain verbose select * into table ramp from road where name
~ '.*Ramp';
QUERY
PLAN
2012/1/11 Euler Taveira de Oliveira :
> On 08-01-2012 11:59, Satoshi Nagayasu / Uptime Technologies, LLC. wrote:
>>> [2011-12-08 15:14:36 JST] 16758: LOG: restored log file
>>> "00080046" from archive
>>> [2011-12-08 15:14:36 JST] 16758: LOG: recoverying 00080046
* Greg Smith:
> One idea I was thinking about here was building a little hash table
> inside of the fsync absorb code, tracking how many absorb operations
> have happened for whatever the most popular relation files are. The
> idea is that we might say "use sync_file_range every time calls
> for
On Wed, Jan 11, 2012 at 4:38 AM, Greg Smith wrote:
> On 1/10/12 9:14 PM, Robert Haas wrote:
>>
>> Based on that, I whipped up the attached patch, which,
>> if sync_file_range is available, simply iterates through everything
>> that will eventually be fsync'd before beginning the write phase and
>>
On Wed, Jan 11, 2012 at 4:33 AM, Tom Lane wrote:
> BTW ... it occurs to me to ask whether we really have a solid use-case
> for having listeners attached to slave servers. I have personally never
> seen an application for LISTEN/NOTIFY in which the listeners were
> entirely read-only. Even if t
On 11/01/12 08:26, Benedikt Grundmann wrote:
> (replying just to you)
Clearly I didn't. Sigh. Getting myself a coffee now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(replying just to you)
On 10/01/12 15:22, Greg Smith wrote:
> On 1/5/12 5:04 AM, Benedikt Grundmann wrote:
> That sort of thing is one reason why all attempts so far to set
> random_page_cost based on physical characteristics haven't gone
> anywhere useful. The setting is sort of overloaded right
65 matches
Mail list logo
