Jeff Davis wrote:
On Fri, 2010-04-09 at 12:50 -0500, Kevin Grittner wrote:
I just thought that if you were adding more type information,
oriented aournd the types themselves rather than index AMs, some form
of inheritence might fit in gracefully.
There are already some specific proposals for i
On Fri, Apr 16, 2010 at 9:47 PM, Greg Smith wrote:
> Robert Haas wrote:
>> Well, why can't they just hang out as dirty buffers in the OS cache,
>> which is also designed to solve this problem?
>
> If the OS were guaranteed to be as suitable for this purpose as the approach
> taken in the database,
On Thu, Apr 15, 2010 at 6:13 PM, Robert Haas wrote:
> On Thu, Apr 15, 2010 at 2:54 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> I've realized another problem with this patch. standby_keep_segments
>>> only controls the number of segments that we keep around for purposes
>>> of strea
Robert Haas wrote:
Well, why can't they just hang out as dirty buffers in the OS cache,
which is also designed to solve this problem?
If the OS were guaranteed to be as suitable for this purpose as the
approach taken in the database, this might work. But much like the
clock sweep approach
On Fri, Apr 16, 2010 at 3:03 AM, Fujii Masao wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
>> I have to admit to finding this confusing. According to the comments:
>>
>> + /*
>> + * Don't emulate the PQexec()'s behavior of returning the
>> last
>> +
On Fri, Apr 16, 2010 at 7:24 PM, Greg Smith wrote:
> Robert Haas wrote:
>> It seems intuitive to me that setting shared_buffers too small will
>> also cause a performance problem, especially for write-heavy
>> workloads, but I'm less sure I can clearly explain why.
>
> More text to add:
>
> When t
Robert Haas wrote:
It seems intuitive to me that setting shared_buffers too small will
also cause a performance problem, especially for write-heavy
workloads, but I'm less sure I can clearly explain why.
More text to add:
When the server needs to allocate more space for reading or writing
b
On Wed, Apr 14, 2010 at 4:18 PM, Greg Smith wrote:
> Kevin Grittner wrote:
>> I wonder if we should add any hints telling people
>> what they might see as problems if they are too far one way or the
>> other. (Or does that go beyond the scope of what makes sense in TFM?)
>
> It's hard to figure t
On Fri, 2010-04-16 at 13:00 +0100, Simon Riggs wrote:
> Almost done
Here's the finished patch.
Internal changes only, no functional or user visible changes, so no
docs, just detailed explanatory comments.
Expectation is
* performance no longer depends upon max_connections
* recovery will be abou
Simon Riggs writes:
> On Fri, 2010-04-16 at 10:39 -0400, Tom Lane wrote:
>> I think you're outsmarting yourself there. A binary search will in fact
>> *not work* with circular xid comparison (this is exactly why there's no
>> btree opclass for XID).
> I don't understand the exact, please explain
On Fri, 2010-04-16 at 10:39 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I didn't handle xid wraparound correctly in the binary search, need to use
> > TransactionIdFollows instead of plan >.
>
> I think you're outsmarting yourself there. A binary search will in fact
> *not work* with
Heikki Linnakangas writes:
> I didn't handle xid wraparound correctly in the binary search, need to use
> TransactionIdFollows instead of plan >.
I think you're outsmarting yourself there. A binary search will in fact
*not work* with circular xid comparison (this is exactly why there's no
btree
On Fri, 2010-04-16 at 14:47 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2010-04-16 at 11:29 +0300, Heikki Linnakangas wrote:
> >> How does the attached patch look like? It's probably similar to what you
> >> had in mind.
> >
> > It looks like a second version of what I'm work
Simon Riggs wrote:
> On Fri, 2010-04-16 at 11:29 +0300, Heikki Linnakangas wrote:
>> How does the attached patch look like? It's probably similar to what you
>> had in mind.
>
> It looks like a second version of what I'm working on and about to
> publish. I'll take that as a compliment!
>
> My pa
On Mon, Mar 22, 2010 at 9:14 PM, Bruce Momjian wrote:
> Takahiro Itagaki wrote:
>>
>> Bruce Momjian wrote:
>>
>> > Takahiro Itagaki wrote:
>> > > Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
>> > > db_encoding_strdup() with the function. Like this:
>> >
>> > OK, I don't
Heikki Linnakangas wrote:
> Andrew Dunstan wrote:
>> Heikki Linnakangas wrote:
>>> I'm going to see what happens if I remove all the #ifdef WIN32 blocks in
>>> syslogger, and let it use pgpipe() and select() instead of the extra
>>> thread.
>> Sounds reasonable. Let's see how big the changes are on
Sorry, I used random_page_cost=2, while random_page_cost=3 didn't help.
Oleg
On Fri, 16 Apr 2010, Oleg Bartunov wrote:
On Thu, 15 Apr 2010, Tom Lane wrote:
Oleg Bartunov writes:
below is an example of interesting query and two plans - the bad plan,
which
uses merge join and big sorting, too
On 15/04 19.31, John R Pierce wrote:
>the 8.4.3 binary tarball for solaris sparc 64bit on postgresql.com was
>shipped with the 32bit includes and the Makefile fragments from
>8.4-community/lib/64/pgxs/src/
>I'm specifically hitting this contradition:
>$ grep FLOAT8 include/s
On Thu, 15 Apr 2010, Tom Lane wrote:
Oleg Bartunov writes:
below is an example of interesting query and two plans - the bad plan, which
uses merge join and big sorting, took 216 sec, and good plan with merge join
disabled took
8 sec.
The "good" plan seems to be fast mainly because of heavil
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Tom Lane wrote:
I'm not sure how much it would help to increase the statistics
targets, but that would be worth trying.
Setting statistics to 1000 helps for that particular reduced query, but
full query (attached) is out of luck.
I notice that t
On Fri, 2010-04-16 at 11:29 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-13 at 21:09 +0300, Heikki Linnakangas wrote:
> >> A quick fix would be to check if there's any entries in the hash table
> >> before scanning it. That would eliminate the overhead when there's no
>
Robert Haas wrote:
> On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
> wrote:
>> We have the emode_for_corrupt_record() function that's used in all the
>> errors that indicate a corrupt WAL record, that's a perfect place to
>> hook this into. See attached patch.
>
> The test for elog == LOG
Fujii Masao wrote:
> One problem of the patch is that even if the content of error message
> is different from the past, it would be skipped when the location of
> invalid record is the same of the past. For example, if there is a
> partially-filled unbroken WAL file in the standby, the following
>
Simon Riggs wrote:
> On Tue, 2010-04-13 at 21:09 +0300, Heikki Linnakangas wrote:
>> A quick fix would be to check if there's any entries in the hash table
>> before scanning it. That would eliminate the overhead when there's no
>> in-progress transactions in the master. But as soon as there's even
On tor, 2010-04-15 at 20:56 -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Apparently, pgindent replaces multiple spaces in comments by a tab
> > (possibly subject to additional logic). An example among thousands:
> >
> > http://git.postgresql.org/gitweb?p=postgresql.git;a=blobdiff_pla
On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
> I have to admit to finding this confusing. According to the comments:
>
> + /*
> + * Don't emulate the PQexec()'s behavior of returning the last
> + * result when there are many, since walreceiver n
26 matches
Mail list logo
