On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas robertmh...@gmail.com 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,
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:
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 one,
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
Robert Haas wrote:
On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
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
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us 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.
On Thu, 15 Apr 2010, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
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
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 o...@sai.msu.su writes:
below is an example of interesting query and two plans - the bad plan,
which
uses merge join and
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 HEAD. I'm
On Mon, Mar 22, 2010 at 9:14 PM, Bruce Momjian br...@momjian.us wrote:
Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
Takahiro Itagaki wrote:
Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
db_encoding_strdup() with the function. Like this:
OK,
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 patch is
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 working on and
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Fri, 2010-04-16 at 10:39 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Simon Riggs si...@2ndquadrant.com 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,
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
On Wed, Apr 14, 2010 at 4:18 PM, Greg Smith g...@2ndquadrant.com 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
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
On Fri, Apr 16, 2010 at 7:24 PM, Greg Smith g...@2ndquadrant.com 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
On Fri, Apr 16, 2010 at 3:03 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas robertmh...@gmail.com wrote:
I have to admit to finding this confusing. According to the comments:
+ /*
+ * Don't emulate the PQexec()'s
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
On Thu, Apr 15, 2010 at 6:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 15, 2010 at 2:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
I've realized another problem with this patch. standby_keep_segments
only controls the number of
On Fri, Apr 16, 2010 at 9:47 PM, Greg Smith g...@2ndquadrant.com 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
25 matches
Mail list logo
