2010/12/7 Robert Haas :
> 2010/12/7 Віталій Тимчишин :
>> As far as I can see from the source, there is a lot of code executed under
>> the partition lock protection, like two hash searches (and possibly
>> allocations).
>
> Yeah, that was my concern, too, though Tom seems skeptical (perhaps
> righ
2010/12/7 Віталій Тимчишин :
> As far as I can see from the source, there is a lot of code executed under
> the partition lock protection, like two hash searches (and possibly
> allocations).
Yeah, that was my concern, too, though Tom seems skeptical (perhaps
rightly). And I'm not really sure why
2010/12/7 Віталій Тимчишин :
>
>
> 2010/12/7 Robert Haas
>>
>> On Tue, Dec 7, 2010 at 1:08 PM, Ivan Voras wrote:
>>
>> > I'm not very familiar with PostgreSQL code but if we're
>> > brainstorming... if you're only trying to protect against a small
>> > number of expensive operations (like DROP, e
Tom Polak wrote:
> I did not tweak anything after installing either system.
PostgreSQL is set up with defaults such that it will start up and
run on the most ancient an underpowered system people are likely to
have lying around. It is expected that people will tune it for
serious production u
On Mon, Dec 6, 2010 at 4:31 PM, felix wrote:
>
> thanks for the replies !,
> but actually I did figure out how to kill it
> but pb_cancel_backend didn't work. here's some notes:
> this has been hung for 5 days:
> ns | 32681 | nssql | in transaction | f | 2010-12-01
> 15
Right, pg
On 07/12/2010 9:29 PM, Tom Polak wrote:
From EXPLAIN ANALYZE I can see the query ran much faster.
"Nested Loop Left Join (cost=0.00..138.04 rows=1001 width=1298) (actual
time=0.036..4.679 rows=1001 loops=1)"
" Join Filter: (pgtemp1.state = pgtemp2.stateid)"
" -> Seq Scan on pgtemp1 (cost=
On 12/7/10 1:29 PM, Tom Polak wrote:
What I was really after was a quick comparison between the two. I did not
create anything special, just the two tables. One table SQL generated the
records for me. I did not tweak anything after installing either system.
That's not a valid test. Postgres
2010/12/7 Robert Haas
> On Tue, Dec 7, 2010 at 1:08 PM, Ivan Voras wrote:
>
> > I'm not very familiar with PostgreSQL code but if we're
> > brainstorming... if you're only trying to protect against a small
> > number of expensive operations (like DROP, etc.) that don't really
> > happen often, w
What I was really after was a quick comparison between the two. I did not
create anything special, just the two tables. One table SQL generated the
records for me. I did not tweak anything after installing either system.
There was a primary key on the ID field of both tables, no indexes though
i
On 12/7/2010 2:10 PM, Kenneth Marshall wrote:
On Tue, Dec 07, 2010 at 11:56:51AM -0800, Richard Broersma wrote:
On Tue, Dec 7, 2010 at 11:43 AM, Andy Colson wrote:
In PG the first statement you fire off (like an "insert into" for example)
will start a transaction. ?If you dont commit before y
Tom Polak wrote:
We are in the process of deciding on how to proceed on a database
upgrade. We currently have MS SQL 2000 running on Windows 2003 (on my
test server). I was shocked at the cost for MS SQL 2008 R2 for a new
server (2 CPU license). I started comparing DB’s and came across
po
On 07/12/2010 7:43 PM, Andy Colson wrote:
On 12/7/2010 1:22 PM, Justin Pitts wrote:
Also, as a fair warning: mssql doesn't really care about
transactions, but
PG really does. Make sure all your code is properly starting and
commiting
transactions.
-Andy
I do not understand that statement
On Tue, Dec 07, 2010 at 11:56:51AM -0800, Richard Broersma wrote:
> On Tue, Dec 7, 2010 at 11:43 AM, Andy Colson wrote:
>
> > In PG the first statement you fire off (like an "insert into" for example)
> > will start a transaction. ?If you dont commit before you disconnect that
> > transaction wil
On Tue, Dec 7, 2010 at 11:43 AM, Andy Colson wrote:
> In PG the first statement you fire off (like an "insert into" for example)
> will start a transaction. If you dont commit before you disconnect that
> transaction will be rolled back. Even worse, if your program does not
> commit, but keeps
On 12/7/2010 1:22 PM, Justin Pitts wrote:
Also, as a fair warning: mssql doesn't really care about transactions, but
PG really does. Make sure all your code is properly starting and commiting
transactions.
-Andy
I do not understand that statement. Can you explain it a bit better?
In mssql
On 12/7/10 9:34 AM, Tom Polak wrote:
We are in the process of deciding on how to proceed on a database upgrade. We
currently have MS SQL 2000 running on Windows 2003 (on my test server). I was
shocked at the cost for MS SQL 2008 R2 for a new server (2 CPU license). I
started comparing DB’s
On 7 December 2010 19:10, Robert Haas wrote:
>> I'm not very familiar with PostgreSQL code but if we're
>> brainstorming... if you're only trying to protect against a small
>> number of expensive operations (like DROP, etc.) that don't really
>> happen often, wouldn't an atomic reference counter
On Tuesday 07 December 2010 18:34:25 Tom Polak wrote:
> Then I did the same test via Postgresql and it took 8.85 seconds! I tried
> it again as I thought I did something wrong. I did a few tweaks such as
> increasing the shared buffers. Still the best I could get it to was 7.5
> seconds. This i
On 12/7/2010 11:34 AM, Tom Polak wrote:
We are in the process of deciding on how to proceed on a database
upgrade. We currently have MS SQL 2000 running on Windows 2003 (on my
test server). I was shocked at the cost for MS SQL 2008 R2 for a new
server (2 CPU license). I started comparing DB’s
Tom Polak wrote:
> the best I could get it to was 7.5 seconds.
> select name,address,city,state,statename,stateid,other from
> pgtemp1 left join pgtemp2 on state=stateid
We'd need a lot more information. Please read this and post again:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
On Tue, Dec 7, 2010 at 1:08 PM, Ivan Voras wrote:
> On 7 December 2010 18:37, Robert Haas wrote:
>> On Mon, Dec 6, 2010 at 9:59 PM, Jignesh Shah wrote:
>>> That's exactly what I concluded when I was doing the sysbench simple
>>> read-only test. I had also tried with different lock partitions and
On Tue, Dec 7, 2010 at 12:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> I wonder if it would be possible to have a very short critical section
>> where we grab the partition lock, acquire the heavyweight lock, and
>> release the partition lock; and then only as a second step record (in
>> the f
On 7 December 2010 18:37, Robert Haas wrote:
> On Mon, Dec 6, 2010 at 9:59 PM, Jignesh Shah wrote:
>> That's exactly what I concluded when I was doing the sysbench simple
>> read-only test. I had also tried with different lock partitions and it
>> did not help since they all go after the same tab
We are in the process of deciding on how to proceed on a database upgrade.
We currently have MS SQL 2000 running on Windows 2003 (on my test server).
I was shocked at the cost for MS SQL 2008 R2 for a new server (2 CPU
license). I started comparing DB’s and came across postgresql. It seemed
to be
Hi Tom
I suspect I may be missing something here, but I think it's a pretty
universal truism that cache lines are aligned to power-of-2 memory
addresses, so it would suffice to ensure during setup that the lower order n
bits of the object address are all zeros for each critical object; if the
mall
Robert Haas writes:
> I wonder if it would be possible to have a very short critical section
> where we grab the partition lock, acquire the heavyweight lock, and
> release the partition lock; and then only as a second step record (in
> the form of a PROCLOCK) the fact that we got it.
[ confused.
On Mon, Dec 6, 2010 at 9:59 PM, Jignesh Shah wrote:
> That's exactly what I concluded when I was doing the sysbench simple
> read-only test. I had also tried with different lock partitions and it
> did not help since they all go after the same table. I think one way
> to kind of avoid the problem
I have encountered a problem while restoring the database. There is a
table that contains XML data (BLOB), ~ 3 000 000 records, ~ 5.5Gb of
data. pg_restore has been running for a week without any considerable
progress. There are plenty of lines like these in the log:
pg_restore: processing ite
28 matches
Mail list logo
