On Wednesday, October 31, 2012 5:47 PM Magnus Hagander wrote:
On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
I should think that doing this requires heading back towards there
being a single unique configuration stream, and over the
Hi, Dear HackersI need to estimate the hashjoin cost in my research. As the
textbook shows, it is 3(R+S) where R and S are the size of the tablesize of the
two tables, which realistically only considers the cost of IO. But this is
obviously too theoretical. What is the correct way to
On 01/11/12 00:25, Baptiste LHOSTE wrote:
Hi All,
We are using postgreSQL since 2007 (now we use postgreSQL 8.4) and until
recently we used to perform vacuum and analyze tasks by ourself. Nevertheless
we reached a point where these tasks are taking so much time that why we decide
to use the
Qi Huang wrote:
I need to estimate the hashjoin cost in my research.
I looked at the code of final_cost_hashjoin() . It is not clear
what factor it is considering. So, except the I/O to and from disk,
what other factors are affecting the cost of hahsjoin?
Claudio wrote :
Oops - forgot to effectively attach the patch.
I've read through your patch and the earlier posts by you and Cédric.
This is very interesting. You chose to prefetch index btree (key-ptr) pages
whereas I chose to prefetch the data pages pointed to by the key-ptr pages.
On Tue, Oct 30, 2012 at 1:50 AM, Claudio Freire klaussfre...@gmail.com wrote:
On Mon, Oct 29, 2012 at 7:07 PM, Cédric Villemain
ced...@2ndquadrant.com wrote:
Well, informing linux hackers may help.
I agree. I'm a bit hesitant to subscribe to yet another mailing list
FYI you can send messages
On Thursday, November 01, 2012 05:53:39 PM Marti Raudsepp wrote:
On Tue, Oct 30, 2012 at 1:50 AM, Claudio Freire klaussfre...@gmail.com
wrote:
On Mon, Oct 29, 2012 at 7:07 PM, Cédric Villemain
ced...@2ndquadrant.com wrote:
Well, informing linux hackers may help.
I agree. I'm a bit
On Thu, Nov 1, 2012 at 1:37 PM, John Lumby johnlu...@hotmail.com wrote:
Claudio wrote :
Oops - forgot to effectively attach the patch.
I've read through your patch and the earlier posts by you and Cédric.
This is very interesting. You chose to prefetch index btree (key-ptr)
pages
On Thu, Nov 1, 2012 at 2:00 PM, Andres Freund and...@2ndquadrant.com wrote:
I agree. I'm a bit hesitant to subscribe to yet another mailing list
FYI you can send messages to linux-kernel without subscribing (there's
no moderation either).
Subscribing to linux-kernel is like drinking from a
On 28 October 2012 01:20, David Lee davidomu...@gmail.com wrote:
It seems like right now when you want to create an index concurrently, the
index creation will get canceled if you cancel the statement (i.e. you must
keep your statement open).
Is there a way to launch an index creation in
Hi,
On Monday 29 October 2012 16:33:25 Tom Lane wrote:
Christian Kruse cjk+postg...@defunct.ch writes:
I created a patch which implements MAP_HUGETLB for sysv shared memory
segments (PGSharedMemoryCreate). It is based on tests of Tom Lane and
Andres Freund, I added error handling, huge
Since I've mentioned my use case, I might as well mention another issue I
stumbled across, which is that concurrent index creation cannot happen from
within trigger functions. I'm able to non-concurrently create indexes from
within trigger functions. Why is there this disparity?
Because
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter da...@fetter.org wrote:
I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have
enough latency for my reflexes to hit ^C fast enough. Any way to
inject this fault deterministically?
If the point is to get this warning, you can
Claudio wrote :
Check the latest patch, it contains heap page prefetching too.
Oh yes I see. I missed that - I was looking in the wrong place.
I do have one question about the way you did it : by placing the
prefetch heap-page calls in _bt_next, which effectively means inside
a call from the
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Btw, I believe that this is correct behavior, because in Peter's case the
manual command gets the priority on the value of synchronous_commit, no?
If anybody thinks that I am wrong, feel free to argue on that of
Hi All,
We are using postgreSQL since 2007 (now we use postgreSQL 8.4) and until
recently we used to perform vacuum and analyze tasks by ourself. Nevertheless
we reached a point where these tasks are taking so much time that why we decide
to use the autovacuum daemon.
But we have some
Parsing log files for commonly needed performance data is no fun. As a
next step toward eliminating that, I've been working on how to approach
this similarly to how pg_stat_statements can cut down on query log
processing. I thought it would be novel to outline this for design
review before
Greg,
First off, let me again praise the great work you and Peter are doing in
this area.
Modeling this on pg_stat_statements includes the hope of packaging it as
an extension with minor core hooks, and the idea that there would be a
fixed size list of timing events available at any time.
On Fri, Nov 2, 2012 at 8:54 AM, Josh Berkus j...@agliodbs.com wrote:
Greg,
First off, let me again praise the great work you and Peter are doing in
this area.
Modeling this on pg_stat_statements includes the hope of packaging it as
an extension with minor core hooks, and the idea that
On 11/1/12 11:54 PM, Josh Berkus wrote:
For example, it would be really useful to be able to
see, for example, pg_stat_user_tables from 2 days ago to estimate table
growth and activity, or pg_stat_replication from 10 minutes ago to
average replication lag.
I don't see all that going into core
On 10/31/12 12:17 PM, Magnus Hagander wrote:
The idea at the time was to use the include *directory* functionality,
for say a config.d directory in pgdata. The builtin one would then
use a predictable filename in this directory, so that the DBA who
prefers it can drop files both before and
On 11/1/12 6:13 PM, Claudio Freire wrote:
posix_fadvise what's the trouble there, but the fact that the kernel
stops doing read-ahead when a call to posix_fadvise comes. I noticed
the performance hit, and checked the kernel's code. It effectively
changes the prediction mode from sequential to
On Thu, Nov 1, 2012 at 10:59 PM, Greg Smith g...@2ndquadrant.com wrote:
On 11/1/12 6:13 PM, Claudio Freire wrote:
posix_fadvise what's the trouble there, but the fact that the kernel
stops doing read-ahead when a call to posix_fadvise comes. I noticed
the performance hit, and checked the
This is a little patch to fix a typo in a comment.
Best regards,
Etsuro Fujit
commentfix_20121102.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sorry, this is not a typo. Please ignore the post.
Best regards,
Etsuro Fujit
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
Sent: Friday, November 02, 2012 2:40 PM
To: 'PostgreSQL-development'
25 matches
Mail list logo
