Hi,
The Current architecture of Updates in PostgreSQL is
1) Make a select query out of update. It involves a READ lock/BUFFER_SHARE
2) Get the tupleid
3) Goto the buffer containing the tupleid, make a BUFFER_EXCLUSIVE lock on
it
4) update it
5) Repeat the above process for subsequent rows
I
Gokulakannan Somsundaram wrote:
Hi,
The Current architecture of Updates in PostgreSQL is
1) Make a select query out of update. It involves a READ lock/BUFFER_SHARE
2) Get the tupleid
3) Goto the buffer containing the tupleid, make a BUFFER_EXCLUSIVE lock on
it
4) update it
5) Repeat the
The obvious advantages are
a) Avoidance of one read lock per page
b) One Big write lock instead of multiple write locks.
But as you said, i will do some initial profiling and get back.
Thanks,
Gokul.
On 9/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somsundaram wrote:
Hi,
On 9/20/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Can you retry both sets of tests but this time in C locale? The lower()
code works differently in C locale, and it might be that we need to look
at tweaking just one case.
Here we go with SQL_ASCII:
** 8.1 **
cityvox_c=# SELECT e.numeve
Peter Eisentraut schrieb:
Pedro Belmino wrote:
I am with a problem. When I am using debugger, breakpoints that they
are inside of main function (stop the execution in the marked point)
but when breakpoint is marked in another archive (index.c for
example) breakpoint does not function (the
Thank you everyone for your valuable input! I will have a look at some other
part of PostgreSQL, and maybe find something else to do instead.
Best,
Georgi
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gregory Stark napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Just for information. Venezuela is going to have new timezone change (30minutes
shift) on this weekend. This change is not yet integrated in the last version
in Olson database. (Original announcement said it happens on 1.1.2008)
while rebuilding pgsql with msvc 2005 I noticed this compiler warning:
.\src\interfaces\ecpg\ecpglib\execute.c(1495): warning C4700:
uninitialized local variable 'prepname' used
ECPGfree(prepname) is called in line 1495, prepname was not
unitialized befor. Below the line 1495
while rebuilding postgres with msvc 2005 I noticed some minor compiler
warnings:
.\src\backend\utils\adt\tsrank.c(24): warning C4305: 'initializing' :
truncation from 'double' to 'float'
.\src\backend\utils\adt\tsrank.c(24): warning C4305: 'initializing' :
truncation from 'double' to 'float'
Howdy,
Here's an updated version of the function stats patch. The biggest change is
that by default only procedural language functions are counted. The GUC variable
stats_function_level now takes 3 values: on, off and all. The latter also
counts SQL and C language functions, on means only to
Guillaume Smet wrote:
app_hls
On 9/20/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Can you retry both sets of tests but this time in C locale? The lower()
code works differently in C locale, and it might be that we need to look
at tweaking just one case.
Please try the
Gokulakannan Somsundaram [EMAIL PROTECTED] writes:
I propose to change this row-by-row approach, when it is a full table
update. I plan to send a extra flag(which will be set for Full table
Deletes/Updates). this would make the access method directly acquire the
exclusive lock and update the
I wrote:
I can't see an obvious way around the problem for multi-byte case -
lower() then requires converting to and from wchar, and I don't see a
way of avoiding calling lower().
There is one way we could reduce the use of lower() by up to (almost)
50% in the common case where the
I've committed the HOT patch. I'd still like to think about whether we
can be smarter about when to invoke pruning, but that's a small enough
issue that the patch can go in without it.
regards, tom lane
---(end of
Thank you, committed
Hannes Eder wrote:
while rebuilding postgres with msvc 2005 I noticed some minor compiler
warnings:
.\src\backend\utils\adt\tsrank.c(24): warning C4305: 'initializing' :
truncation from 'double' to 'float'
.\src\backend\utils\adt\tsrank.c(24): warning C4305:
Tom Lane wrote:
I've committed the HOT patch.
Thanks, much easier to work with it now that it's in.
I'd still like to think about whether we
can be smarter about when to invoke pruning, but that's a small enough
issue that the patch can go in without it.
Yeah. I'm doing some
On 9/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Tom Lane wrote:
I've committed the HOT patch.
Thanks, much easier to work with it now that it's in.
I'd still like to think about whether we
can be smarter about when to invoke pruning, but that's a small enough
issue that the
Gregory Stark [EMAIL PROTECTED] writes:
Silence Solaris compiler warnings, per buildfarm.
This one was also lost in the tsearch merge.
Done.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the
We are pleased to announce an upcoming patch to the hash index code
which improves build time and index size, based on this item in the
TODO list:
During index creation, pre-sort the tuples to improve build speed
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
Using our
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
Tom Lane wrote:
There might be another way to manage this, but we're not inventing
a new invalidation mechanism for 8.3. This patch will have to be
reverted for the time being :-(
Thanks. Seems it was a good judgement call to apply it only to HEAD,
after all.
In any case, at that point we
Hi,
I am Sri Ramadoss from, Chennai, India interested in forming taking up the
responsibility of Localising Postgre into my native language Tamil.
I am also interested in forming a Community for Postgre in TamilNadu, a State
of India. Tamil is spoken by around 70 million people across the
Alvaro Herrera [EMAIL PROTECTED] writes:
In any case, at that point we are mostly done with the expensive steps
of vacuuming, so the transaction finishes not long after this. I don't
think this issue is worth inventing a new invalidation mechanism.
Yeah, I agree --- there are only a few
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd still like to think about whether we
can be smarter about when to invoke pruning, but that's a small enough
issue that the patch can go in without it.
Yeah. I'm doing some micro-benchmarking, and the attached test case is
much
Hi,
I encountered segfaults in a multi-threaded ecpg application. It uses
PREPARE statements concurrently in several threads. The cause seems to
be the global variable 'prep_stmts' in ecpg/ecpglib/prepare.c .
It is accessed without any locks.
I'm trying to fix it, but there are some approaches
I wrote:
... so basically it's all about the locking. Maybe the problem is that with
HOT we lock the buffer too often? heap_page_prune_opt is designed to
not take the buffer lock unless there's a good probability of needing
to prune, but maybe that's not working as intended.
Indeed it seems
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
Shouldn't we be able to prune rows that have been inserted and deleted
by the same transaction? I'd have hoped to see this example use only
one heap page ...
Not before the transaction commits ? In the test, we update a single tuple
1 times
Pavan Deolasee [EMAIL PROTECTED] writes:
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
Shouldn't we be able to prune rows that have been inserted and deleted
by the same transaction? I'd have hoped to see this example use only
one heap page ...
Not before the transaction commits ? In the
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
but control never gets that far because neither xmin nor xmax is
committed yet. We could fix that, probably, by considering the
xmin=xmax case in the xmin-in-progress case further up; but the
HEAP_UPDATED exclusion is still a problem. Still,
29 matches
Mail list logo
