Heikki Linnakangas 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 patch can go in without it.
Hi Tom,
Thanks for the feedback. Let me clarify my intention again.
This was thought for improving the performance of the Data Warehousing
applications
Full table updates similar to
Update dd set n2=n2+1
When you talked about firing triggers, i looked into the implementation of
triggers
Hi
I have just installed PostgreSQL 8.1 on a Windows XP system with a
NTFS filesystem. Everything seemed to work fine until I executed the
command promt option from the PostgreSQL start button.
I wanted to create my first database by typing createdb mydb and
was asked for my password.
On 9/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
This might be a simplistic question but if the page is +90% full and
there is a long-lived transaction, isn't Postgres going to try pruning
on each page read access?
The way it stands today, yes. Thats one reason why we are seeing
the
Bruce Momjian wrote:
This might be a simplistic question but if the page is +90% full and
there is a long-lived transaction, isn't Postgres going to try pruning
on each page read access?
Yes :(. That's why we earlier talked about stored the xid of the oldest
deleted tuple on the page in the
Tom Lane wrote:
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
Andrew,
On 9/20/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Please try the attached patch, which goes back to using a special case
for single-byte ILIKE. I want to make sure that at the very least we
don't cause a performance regression with the code done this release. I
can't see an obvious
ஆமாச்சு wrote:
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
Guillaume Smet [EMAIL PROTECTED] wrote:
It's better but still slower than 8.2.
It probablly comes from 'var-varlena' feature in 8.3. Now we store
text fields in a compact format on disks and extract them on access.
It consumes some CPU cycles. If all of data are in buffer cache
and the
Gokulakannan Somsundaram wrote:
Again if this full table updates are thought with the OLTP applications in
mind, then this is not at all a suitable option. This will only benefit the
people with Data Warehouses.
Expecting some more replies
Start with profiling.
I just ran a quick
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Guillaume Smet [EMAIL PROTECTED] wrote:
It's better but still slower than 8.2.
It probablly comes from 'var-varlena' feature in 8.3. Now we store
text fields in a compact format on disks and extract them on access.
It consumes some CPU cycles. If
On Fri, Sep 21, 2007 at 11:05:47AM +0900, ITAGAKI Takahiro wrote:
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.
And it is global, right. This has to be fixed, you're
Regarding this item in the TODO:
SQL*Net listener that makes PostgreSQL appear as an Oracle database
to clients
I recently had (an unrelated) reason to look into the SQL*Net protocol
and discovered that no documentation for it is publicly available, and
reverse-engineering it is
Michael Meskes [EMAIL PROTECTED] wrote:
Right now the prepared statements are not considered connection
specific. I'm not sure whether the standard says anything about this.
But moving this data shoudln't be a major problem.
Even if we have some kinds of exclusive controls, current ecpg
Merlin Moncure wrote:
On 9/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Yeah. I'm doing some micro-benchmarking, and the attached test case is
much slower with HOT. It's spending a lot of time trying to prune, only
to find out that it can't.
Instead of/in addition to avoiding pruning
Am Freitag, 21. September 2007 schrieb Abhijit Menon-Sen:
Regarding this item in the TODO:
SQL*Net listener that makes PostgreSQL appear as an Oracle database
to clients
(IMO, the TODO item should be dropped.)
Yeah, if at all, this should be an external proxy server.
--
Peter
Merlin Moncure wrote:
On 9/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Yeah. I'm doing some micro-benchmarking, and the attached test case is
much slower with HOT. It's spending a lot of time trying to prune, only
to find out that it can't.
Instead of/in addition to avoiding pruning
On Thu, Sep 20, 2007 at 02:05:57PM +0200, Hannes Eder wrote:
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
This free() call seems to be absolutely superfluous,
On Wed, 2007-09-19 at 10:37 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We're able to dynamically add AMs in the way you suggest, but there is
no way to alter the RMgrTable to either add a new RM or re-assign one of
the unused RMs.
Hmmm...
1. Remove the Const in
This appears to be a usage question. -hackers is about development of
Postgres, not use. Please ask in the correct forum.
Also, when you do ask on the correct list, please add more detail to
questions like this. In particular, show code that you have tried and
that didn't work like you
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
so this example is getting past the heuristic tests in
heap_page_prune_opt almost every time. Why is that? Too tired to poke
at it more tonight.
I guess you already know the answer now, but anyways: Since we are
updating a single tuple in a
I was wondering how to access the schema of a type in PL/PGSQL
Basically, we've created some custom objects in the database, which
are somewhat similar to database/composite types (i.e. Create type..)-
essentially a named list of name/type pairs.
In PL/PGSQL you can define variables to be custom
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
It shouldn't, though --- the hint bit should get cleared on the first
try. I think I probably broke something in the last round of revisions
to heap_page_prune_opt, but haven't looked yet ...
We set the hint bit (prunable) again when we see a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
This might be a simplistic question but if the page is +90% full and
there is a long-lived transaction, isn't Postgres going to try pruning
on each page read access?
Yes :(
It shouldn't, though --- the hint bit should get
Tom Lane wrote:
I don't much like the idea of adding an xid to the page header --- for
one thing, *which* xid would you put there, and what would you test it
against?
I was thinking that you would put the smallest in-progress xmax on the
page there, and you would test it against OldestXmin. If
Heikki Linnakangas [EMAIL PROTECTED] writes:
If you look at the callgraph, you'll see that those
LWLockAcquire/Release calls are coming from HeapTupleSatisfiesVacuum -
TransactionIdIsInProgress, which keeps trashing the ProcArrayLock. A
if(TransactionIdIsCurrentTransactionId(xid)) return true;
Pavan Deolasee [EMAIL PROTECTED] writes:
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
so this example is getting past the heuristic tests in
heap_page_prune_opt almost every time. Why is that? Too tired to poke
at it more tonight.
I guess you already know the answer now, but anyways:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
This might be a simplistic question but if the page is +90% full and
there is a long-lived transaction, isn't Postgres going to try pruning
on each page read access?
Yes :(
It shouldn't, though --- the
blay bloo [EMAIL PROTECTED] writes:
I was wondering how to access the schema of a type in PL/PGSQL
Basically, we've created some custom objects in the database, which
are somewhat similar to database/composite types (i.e. Create type..)-
essentially a named list of name/type pairs.
Is there a
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
If you look at the callgraph, you'll see that those
LWLockAcquire/Release calls are coming from HeapTupleSatisfiesVacuum -
TransactionIdIsInProgress, which keeps trashing the ProcArrayLock. A
I wrote:
Dunno about more general, but your idea reduces the runtime of this
example by about 50% (22.2s to 10.5s) for me. I'm worried though that
it would be a net negative in more typical situations, especially if
you've got a lot of open subtransactions.
Actually ... the only way that
On 9/21/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
pre hot:
run 1: 3617.641 ms
run 2: 5195.215 ms
run 3: 6760.449 ms
after vacuum:
run 1: 4171.362 ms
run 2: 5513.317 ms
run 3: 6884.125 ms
post hot:
run 1: Time: 7286.292 ms
run 2: Time: 7477.089 ms
Gregory,
On 9/21/07, Gregory Stark [EMAIL PROTECTED] wrote:
Hm, it does seem I missed like.c when I converted all the text operators to
avoid detoasting packed varlenas. I'll send a patch in a few minutes to do
that. I'm surprised it would have such a large effect though.
The patch doesn't
Merlin Moncure wrote:
Well, my first round of results are so far not showing the big gains I
saw with hot in some of the earlier patches...so far, it looks
approximately to be a wash although with the reduced need to vacuum.
i'll test some more when things settle down.
Oh... Which version did
Tom Lane wrote:
Actually ... the only way that TransactionIdIsCurrentTransactionId can
take a meaningful amount of time is if you've got lots of
subtransactions, and in that case your own subxids cache has certainly
overflowed, which is likely to force TransactionIdIsInProgress into the
slow
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yeah. I played with this a bit more, and came up with a couple of other
micro-optimizations:
1. Instead of pallocing and pfreeing a new array in
TransactionIdIsInProgress, we could just malloc the array once and reuse
it. That palloc/pfree alone
Guillaume Smet [EMAIL PROTECTED] writes:
Gregory,
On 9/21/07, Gregory Stark [EMAIL PROTECTED] wrote:
Hm, it does seem I missed like.c when I converted all the text operators to
avoid detoasting packed varlenas. I'll send a patch in a few minutes to do
that. I'm surprised it would have such
On 9/21/07, Tom Lane [EMAIL PROTECTED] wrote:
I'm also starting to come around to liking the page-header-xid field
a bit more. I suggest that it could replace the page is prunable
flag bit altogether --- to mark the page prunable, you must store
some appropriate xid into the header field.
Heikki Linnakangas [EMAIL PROTECTED] writes:
We've already checked that the xmin is our own transaction id, so we
check if the xmax is an aborted subtransaction of our own transaction. A
TransactionIdDidAbort call seems like an awfully expensive way to check
that. We could call
Hi hackers,
I've noticed that there is a lot of code, particularly in src/backend,
that goes through the motions of making a text datum into a cstring to
perform some work on it, and likewise for making a cstring into a text
datum.
Is there not a nice macro somewhere to handle this consistently?
Heikki Linnakangas [EMAIL PROTECTED] writes:
I noted that most callers of TransactionIdIsInProgress in tqual.c
already call TransactionIdIsCurrentTransactionId before
TransactionIdIsInProgress. In those cases we could just skip the test
for our own xids altogether, if it's worth code mangling
Brendan Jurd [EMAIL PROTECTED] writes:
Surely having the exact same four lines of code written out in dozens
of places is a Bad Thing, but perhaps there is some reasoning behind
this that I am missing?
The canonical way to do it is with
DatumGetCString(DirectFunctionCall1(textout, t))
--
On 9/22/07, Gregory Stark [EMAIL PROTECTED] wrote:
The canonical way to do it is with
DatumGetCString(DirectFunctionCall1(textout, t))
Ah, I see. Thanks.
In that case, would it be helpful if I submitted a patch for the
various code fragments that do this locally, updating them to use
Guillaume Smet wrote:
Gregory,
On 9/21/07, Gregory Stark [EMAIL PROTECTED] wrote:
Hm, it does seem I missed like.c when I converted all the text operators to
avoid detoasting packed varlenas. I'll send a patch in a few minutes to do
that. I'm surprised it would have such a large effect
Brendan Jurd [EMAIL PROTECTED] writes:
On 9/22/07, Gregory Stark [EMAIL PROTECTED] wrote:
The canonical way to do it is with
DatumGetCString(DirectFunctionCall1(textout, t))
Ah, I see. Thanks.
In that case, would it be helpful if I submitted a patch for the
various code fragments that
On 9/22/07, Gregory Stark [EMAIL PROTECTED] wrote:
The canonical way to do it is with
DatumGetCString(DirectFunctionCall1(textout, t))
I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
#define TextPGetCString(t)
DatumGetCString(DirectFunctionCall1(textout,
Well, a couple of specific cases that I came across are
quote_identifier() in src/backend/utils/adt/quote.c, and
do_to_timestamp() in src/backend/utils/adt/formatting.c (line 3349).
I was getting a rough notion of how common the duplication was using
$ egrep -Rn -C 2 'memcpy.*VARDATA'
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
There is one wacky idea I haven't dared to propose yet:
We could lift the limitation that you can't defragment a page that's
pinned, if we play some smoke and mirrors in the buffer manager. When
you prune a page, make
Brendan Jurd [EMAIL PROTECTED] writes:
I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
#define TextPGetCString(t)
DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(t)))
#define CStringGetTextP(c) DatumGetTextP(DirectFunctionCall1(textin,
49 matches
Mail list logo
