On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wrote:
> One change that I would like to get into beta2 is the proposed
> refactoring of some of the new system info / administration functions.
Ok, this is done: the changes have been committed to CVS HEAD and the
catalog version number has been bump
Title: Message
Hi,
I have a query on sql_numeric
datatype Can you please clarify on this?
While inserting numeric data type into a
table can you please let me know how you are storing the value in the
database.
Whether it is stored as double or character or
directly
Gregory Maxwell <[EMAIL PROTECTED]> writes:
> If I had to guess I might say that the 64byte alignment is removing
> much of the unneeded line bouncing in the the two process case but is
> at the same time creating more risk of bouncing caused by aliasing.
It's an idea ... not sure if it's right or
On 9/15/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yesterday's CVS tip:
> 1 32s 2 46s 4 88s 8 168s
> plus no-cmpb and spindelay2:
> 1 32s 2 48s 4 100s 8 177s
> plus just-committed code to pad LWLock to 32:
> 1 33s 2 50s 4 98s 8 179s
> alter to pad to 64:
>
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thursday 15 September 2005 15:41, Alvaro Herrera wrote:
>> Robert Treat reminded me the other day that we don't currently save
>> pg_autovacuum settings on pg_dump.
> ISTM this is a backwards incompatibility with previous installations that
> might h
On Thu, 2005-15-09 at 22:31 -0400, Tom Lane wrote:
> I thought we'd more or less dropped that idea based on Andreas'
> responses.
I've heard no argument against renaming pg_complete_relation_size() to
pg_total_relation_size() and changing the functions that return an
integer status code to make th
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Interesting. On Xeon (2 phys, 4 log), with LWLock padded to 64 bytes and
> the cmpb/jump removed I get:
> [ 1 55s 2 69s 4 128s ]
> This compares to the following, which is unpadded but has cmpb/jump
> removed but is otherwise vanilla:
> 1: 55: 2: 1
Neil Conway <[EMAIL PROTECTED]> writes:
> One change that I would like to get into beta2 is the proposed
> refactoring of some of the new system info / administration functions.
I thought we'd more or less dropped that idea based on Andreas'
responses.
regards, tom lane
-
On Thursday 15 September 2005 15:41, Alvaro Herrera wrote:
> Hi,
>
> Robert Treat reminded me the other day that we don't currently save
> pg_autovacuum settings on pg_dump.
> Does it merit a mention on the release notes?
>
ISTM this is a backwards incompatibility with previous installations th
On Thu, 2005-15-09 at 21:09 -0300, Marc G. Fournier wrote:
> Tomorrow afternoon, we are planning on packaging up Beta2 .. if anyone is
> sitting on something that should get in before that happens, or has a bug
> they are sitting on, please let us know ...
One change that I would like to get int
Gregory Maxwell <[EMAIL PROTECTED]> writes:
> might be useful to align the structure so it always crosses two lines
> and measure the performance difference.. the delta could be basically
> attributed to the cache line bouncing since even one additional bounce
> would overwhelm the other performanc
On Thu, 15 Sep 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > What about padding the LWLock to 64 bytes on these architectures. Both P4
> > and Opteron have 64 byte cache lines, IIRC. This would ensure that a
> > cacheline doesn't hold two LWLocks.
>
> I tried that first, act
Tomorrow afternoon, we are planning on packaging up Beta2 .. if anyone is
sitting on something that should get in before that happens, or has a bug
they are sitting on, please let us know ...
I am planning on wrapping things at around noon my time (~3pm GMT, I
believe, if I have my timezones
Gavin Sherry <[EMAIL PROTECTED]> writes:
> What about padding the LWLock to 64 bytes on these architectures. Both P4
> and Opteron have 64 byte cache lines, IIRC. This would ensure that a
> cacheline doesn't hold two LWLocks.
I tried that first, actually, but it was a net loss. I guess enlarging
> Tom Lane wrote
> I'm going to go ahead and make that change, since it doesn't
> seem likely
> to have any downside. It might be interesting to look into forcing
> proper alignment of the shared buffer headers as well.
Just catching up on your mails - all of that sounds good so far.
Everything
On Thu, 15 Sep 2005, Tom Lane wrote:
> One thing that did seem to help a little bit was padding the LWLocks
> to 32 bytes (by default they are 24 bytes each on x86_64) and ensuring
> the array starts on a 32-byte boundary. This ensures that we won't have
> any LWLocks crossing cache lines --- con
On Thursday 04 August 2005 09:37, Gavin M. Roy wrote:
> You can send it to me, and ehpg will host it. I'll send you a
> private email with my info.
>
> Gavin
>
> On Aug 4, 2005, at 8:26 AM, Mark Woodward wrote:
> > It is 4.4G in space in a gzip package.
> >
> > I'll mail a DVD to two people who pr
I wrote:
> I guess what this means is that there's no real problem with losing the
> cache line while manipulating the LWLock, which is what the patch was
> intended to prevent. Instead, we're paying for swapping two cache lines
> (the spinlock and the LWLock) across processors instead of just one
Tom Lane wrote:
I guess what this means is that there's no real problem with losing the
cache line while manipulating the LWLock, which is what the patch was
intended to prevent. Instead, we're paying for swapping two cache lines
(the spinlock and the LWLock) across processors instead of just on
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Expected or not, fact is it's not user friendly. We should at least
> document this somewhere so users can take care of it by themselves. Not
> sure where does it belong though. The autovacuum section, the backup
> section? Does it merit a mention on
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Cool. I wonder if the exact figure should be
> min(lowest non-frozen Xid in table, GetOldestXmin(false))
Actually just min(lowest Xid in table, RecentXmin). You only need to be
sure there are no running transactions older than what you put into the
fi
Hi,
Robert Treat reminded me the other day that we don't currently save
pg_autovacuum settings on pg_dump. This is expected, because we don't
want to dump pg_autovacuum as a regular table, or it would force us to
accept loading that forever; nor we do have ALTER TABLE commands to do
it on a highe
On Wed, Sep 14, 2005 at 11:30:52PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In fact this seems pretty easy to do. Add a field to pg_class, tell
> > VACUUM to update it using the determined freezeLimit, and that's it.
>
> I think that it'd be worth fixing things so t
>Hi, i didn't know where to send this, so forgive me if this isn't the
right >list.
probably general.
> compiled pl/pgsql script that "remembers" the OID of temporary tables,
Have you considered that if the temp table is created outside of the
function that uses it, this is not a problem?
Ma
Hi, i didn't know
where to send this, so forgive me if this isn't the right
list.
In our company we
had been using PostgreSQL for development for more than 2 years now, it's an
excelent RDBMS, the only thing we miss is the ability to call
stored procedures (functions returning records in PG
while you are at it, can you put in some audit timestamps as to when the vacuum
occurred (full vs not full).
-- Original Message ---
From: Alvaro Herrera <[EMAIL PROTECTED]>
To: Hackers
Sent: Wed, 14 Sep 2005 22:14:23 -0400
Subject: [HACKERS] Per-table freeze limit proposal
>
# [EMAIL PROTECTED] / 2005-09-13 12:17:06 -0400:
> Roman Neuhauser <[EMAIL PROTECTED]> writes:
> > Looking at src/pl/plpgsql/src/pl_exec.c for the first time, is it a problem
> > of make_tuple_from_row() not accounting for nested composite types?
>
> Looks that way. I've committed a fix to HEAD.
alvora,
what concerns me here: this is a sun system and the problem happened
during normal operation.
there should not be a recovery related operation. something which is
also interesting: there are two corrupted pages in there (page number
22 and 26).
strange thing :(.
thanks a lot,
On Wed, Sep 14, 2005 at 10:42:36PM -0400, Tom Lane wrote:
> The thing that's still fairly unclear to me is whether the collation
> information is attached to the operators/functions or to the data.
> I recall there's been some discussion of sticking collation IDs into
> individual text Datums, whic
29 matches
Mail list logo
