On Wed, 16 Jan 2013, Andres Freund wrote:
So unless somebody suggest otherwise, i'm going to switch to gcc on this
buildfarm.
What about switching to -O1 of 11.1?
I don't know. It is up to -hackers to decide. I think that icc on ia64
have shown bugginess time after time. But if you think tha
Hi,
On Wed, 16 Jan 2013, Andres Freund wrote:
On 2013-01-16 01:28:09 -0500, Tom Lane wrote:
It's a compiler bug.
Thanks for investigating. But I'm not sure there is any way other way for
me other than switching to gcc, because intel stopped providing their
IA64 version of compilers free of
On Tue, 15 Jan 2013, Tom Lane wrote:
BTW, I just finished trying to reproduce this on an IA64 machine
belonging to Red Hat, without success. So that seems to eliminate
any possibility of the machine architecture being the trigger issue.
The compiler's still a likely cause though.
Anybody have a
On Tue, 15 Jan 2013, Andres Freund wrote:
Any chance you could run make check again but with log_statement=all and
log_min_messages=debug2? That might tell us a bit more, whether the
dependency code doesn't work right or whether the checkpoint is doing
strange things.
Here it is :
2013-01-15
Hi,
Date: Tue, 15 Jan 2013 11:57:07 -0500
From: Tom Lane
To: Andres Freund
Cc: m...@sai.msu.ru, pgsql-hackers@postgreSQL.org,
Andrew Dunstan
Subject: Re: Curious buildfarm failures
Well, it could be quite reproducible, if for example what's happening is
that the DROP is failing to wait fo
On Sun, 2 Sep 2012, Peter Geoghegan wrote:
On 2 September 2012 16:26, Sergey Koposov wrote:
That's why we support altering that value with an ALTER TABLE...ALTER
COLUMN DDL statement. You might at least consider increasing the
statistics target for the column first though, to see if that
On Sun, 2 Sep 2012, Tom Lane wrote:
Sergey Koposov writes:
The problem is definitely the misestimation here:
-> Index Scan using data_objid_idx on data d1 (cost=0.00..26603.32
rows=415080 width=40) (actual time=0.010..0.050 rows=248 loops=11456)
Index Cond: (ob
Thanks for your comments.
On Sun, 2 Sep 2012, Peter Geoghegan wrote:
On 2 September 2012 06:21, Sergey Koposov wrote:
I think that this kind of question is better suited to the
pgsql-performance list. Granted, it was presented as a bug report
(though they're generally sent to -bugs rather
On Sun, 2 Sep 2012, Pavel Stehule wrote:
statistics on data_objid_idx table are absolutly out - so planner
cannot find optimal plan
That doesn't have anything to do with the problem, AFAIU.
First, the data table is static and was analysed.
Second, the query in question is the join, and afaik
Hi,
I'm experiencing the case when bitmap scan is ~ 70 times slower than
index scan which seems to be caused by 1) very big table 2) some hash
search logic (hash_search_with_hash_value )
Here is the explain analyze of the query with bitmap scans allowed:
wsdb=> explain analyze select * from
On Thu, 7 Jun 2012, Tom Lane wrote:
I extended the patch to also cover DropDatabaseBuffers,
FlushRelationBuffers, and FlushDatabaseBuffers, which have got the exact
same type of full-pool scan loop, and committed it.
Thanks everybody for the patches/commits.
Sergey
***
On Tue, 5 Jun 2012, Simon Riggs wrote:
Sounds less good and we'd need reasonable proof it actually did
anything useful without being dangerous.
Doing an initial unlocked test speeds things up another 2.69 fold (on
top of 3.55 for your patch) for me, with 1GB of shared buffers. That
seems like
On Wed, 6 Jun 2012, Merlin Moncure wrote:
I think this is the expected result. In the single user case the
spinklock never spins and only has to make the cpu-locking cache
instructions once. can we see results @24 threads?
Here
https://docs.google.com/open?id=0B7koR68V2nM1NDJHLUhNSS0zbUk
*
On Wed, 6 Jun 2012, Ants Aasma wrote:
On Wed, Jun 6, 2012 at 2:27 PM, Sergey Koposov wrote:
I've quickly tested your lockfree-getbuffer.patch patch with the test case
you provided and I barely see any improvement (2% at max)
https://docs.google.com/open?id=0B7koR68V2nM1QVBxWGpZdW4wd0U
t
Hi,
On Mon, 4 Jun 2012, Ants Aasma wrote:
On Mon, Jun 4, 2012 at 7:44 PM, Merlin Moncure wrote:
I tried to keep it simple at first to find an answer to the question
if it's even worth trying before expending large effort on it. If
anyone with a multisocket machine would chip in, I'd love to kno
On Thu, 31 May 2012, Jeff Janes wrote:
No, idt_match is getting filled by multi-threaded copy() and then joined
with 4 other big tables like idt_phot. The result is then split into
partitions.
That does make things more complicated. But you could you partition
it at that level and then do th
On Fri, 1 Jun 2012, Simon Riggs wrote:
Why do you have 10,000 tables and why is it important to drop them so quickly?
1 tables are there, because that's the number of partitions. And I'm
dropping them at the moment, because I'm doing testing. So it won't be
really crucial for production.
On Thu, 31 May 2012, Simon Riggs wrote:
That struck me as a safe and easy optimisation. This was a problem I'd
been trying to optimise for 9.2, so I've written a patch that appears
simple and clean enough to be applied directly.
Thanks! The patch indeed improved the timings,
The dropping of
On Thu, 31 May 2012, Robert Haas wrote:
Oh, ho. So from this we can see that the problem is that we're
getting huge amounts of spinlock contention when pinning and unpinning
index pages.
It would be nice to have a self-contained reproducible test case for
this, so that we could experiment with
On Wed, 30 May 2012, Jeff Janes wrote:
But the question now is whether there is a *PG* problem here or not, or is
it Intel's or Linux's problem ? Because still the slowdown was caused by
locking. If there wouldn't be locking there wouldn't be any problems (as
demonstrated a while ago by just cat
On Thu, 31 May 2012, Florian Pflug wrote:
Wait, so performance *increased* by spreading the backends out over as
many dies as possible, not by using as few as possible? That'd be
exactly the opposite of what I'd have expected. (I'm assuming that cores
on one die have ascending ids on linux. If
On Wed, 30 May 2012, Florian Pflug wrote:
I wonder if the huge variance could be caused by non-uniform
synchronization costs across different cores. That's not all that
unlikely, because at least some cache levels (L2 and/or L3, I think) are
usually shared between all cores on a single die. T
On Wed, 30 May 2012, Merlin Moncure wrote:
How big is idt_match? What if you drop all indexes on idt_match,
encouraging all the backends to do hash joins against it, which occur
in local memory and so don't have contention?
You just missed his post -- it's only 3G. can you run your 'small'
On Wed, 30 May 2012, Merlin Moncure wrote:
hurk -- ISTM that since IOS is masikng the heap lookups, there must
be contention on the index itself? Does this working set fit in
shared memory? If so, what happens when you do a database restart and
repeat the IOS test?
The dataset fits well in
On Wed, 30 May 2012, Merlin Moncure wrote:
Hm, why aren't we getting a IOS? Just for kicks (assuming this is
test data), can we drop the index on just transitid, leaving the index
on transitid, healpixid?Is enable_indexonlyscan on? Has idt_match
been vacuumed? What kind of plan do you get
On Wed, 30 May 2012, Merlin Moncure wrote:
1. Can we see an explain analyze during a 'bogged' case?
Here is the one to one comparison of the 'bogged'
**
QUERY PLAN
Here is the actual explain analyze of the query on the smaller dataset
which I have been using for the recent testing.
test=# explain analyze create table _tmp0 as select * from
( select *,
(select healpixid from idt_match as m where m.transitid=o.transitid)
as x from id
Hello,
I was running some tests on PG9.2beta where I'm creating and dropping
large number of tables (~ 2).
And I noticed that table dropping was extremely slow -- e.g. like half a
second per table.
I tried to move the table dropping into bigger transactions (100 per one
transaction) (i
1.4
7 13.3
8 16.1
9 19.0
10 21.4
11 23.8
12 27.3
13 30.2
14 32.0
15 34.1
16 37.5
Regards,
Sergey
On Sat, 26 May 2012, Stephen Frost wrote:
* Sergey Koposov (kopo...@ast.cam.ac.uk) wrote:
Turning off synch seq scans doesn't help either. 18 sec
multithreaded run vs 7 sec singl
On Sat, 26 May 2012, Stephen Frost wrote:
Alright, can you just time 'cat' when they're started a few seconds or
whatever apart from each other? I can't imagine it being affected in
the same way as these, but seems like it wouldn't hurt to check.
I've tryed cat'ting a created in advance 8gig
On Sat, 26 May 2012, Robert Haas wrote:
This theory is seeming fairly plausible - how can we test it?
How about trying it with synchronize_seqscans = off? If the
synchronized-seqscan logic is causing contention on the buf mapping
locks and individual buffer locks, that should fix it.
Turning
On Fri, 25 May 2012, Merlin Moncure wrote:
can you hack this in heapam.c and see if it helps?
line 131-ish:
if (!RelationUsesLocalBuffers(scan->rs_rd) &&
scan->rs_nblocks > NBuffers / 4)
becomes
if (!RelationUsesLocalBuffers(scan->rs_rd))
(also you can set the pa
On Fri, 25 May 2012, Robert Haas wrote:
On Thu, May 24, 2012 at 7:26 PM, Sergey Koposov wrote:
Here is the output from a multi-threaded run (8thtreads, 22 seconds) sorted
by blk. Not sure whether that's of much use or not:
What are the top dozen or so entries if you sort by shacq?
He
On Fri, 25 May 2012, Merlin Moncure wrote:
how likely is it to see multiple simultaneous scans in the real world?
Interleaving scans like that is not a very effective optimization --
if it was me, it'd be trying to organize something around a
partitioned tid scan for parallel sequential access.
On Fri, 25 May 2012, Merlin Moncure wrote:
These are all on the buffer partition locks. That makes sense...I was
wrong earlier: this case was in fact 'create table as', not 'insert
select' which rules out both the freelist lock and the wal insert lock
because create table as gets to use both a
On Thu, 24 May 2012, Jeff Janes wrote:
Add
#define LWLOCK_STATS
near the top of:
src/backend/storage/lmgr/lwlock.c
and recompile and run a reduced-size workload. When the processes
exits, they will dump a lot of data about LWLock usage to the logfile.
Generally the LWLock with the most blocks o
Hi,
On Thu, 24 May 2012, Robert Haas wrote:
Not sure. It might be some other LWLock, but it's hard to tell which
one from the information provided.
If you could tell what's the best way to find out the info that you need,
then I could run it reasonably quickly.
S
*
On Thu, 24 May 2012, Robert Haas wrote:
As you can see, raw performance isn't much worse with the larger data
sets, but scalability at high connection counts is severely degraded
once the working set no longer fits in shared_buffers.
Actually the problem persits even when I trim the dataset si
On Thu, 24 May 2012, Robert Haas wrote:
On Thu, May 24, 2012 at 1:42 PM, Sergey Koposov wrote:
I guess there is nothing catastrophically wrong with that, but still I'm
very suprised that you get severe locking problems (factor of two slow-down)
when running parallel read-only transac
On Thu, 24 May 2012, Merlin Moncure wrote:
Are you sure? I looked at all the ReleasePredicateLocks calls and
they appear to be guarded by:
/* Nothing to do if this is not a serializable transaction */
if (MySerializableXact == InvalidSerializableXact)
return false;
Hi,
I've been running some tests on pg 9.2beta1 and in particular a set
of queries like
create table _tmp0 as select * from (
select *, (select healpixid from idt_match as m where
m.transitid=o.transitid)
as x from idt_photoobservat
41 matches
Mail list logo
