"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,
> CStrin
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 pr
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' src/backend
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, Point
"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 cod
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 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
Dat
"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))
"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 ma
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:
> 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 Transact
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 head
"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 w
"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
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
> "
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
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'
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
> > r
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 tha
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
>> "if(TransactionIdIsCurrentT
"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
"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)) ret
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.
"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 no
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
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
"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 sho
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
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 expec
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 "
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 superfluou
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
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 avoidi
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 avoidi
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 (supposed
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
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 rig
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 o
"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
ஆமாச்சு 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 p
"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 enc
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 obv
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,
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
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
t
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. Ev
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 a
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 wit
49 matches
Mail list logo
