Bruce Momjian <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
> > But I think this is a dead-end route. What you're looking at is the number
> > "1"
> > repeated for *every* record in the table. And what your proposing amounts to
> > noticing that the number "4" fits in a byte and doesn't need
Gregory Stark wrote:
> I think we have to find a way to remove the varlena length header
> entirely for fixed length data types since it's going to be the same
> for every single record in the table.
But that won't help in the example you posted upthread, because char(N)
is not fixed-length.
--
Gregory Stark wrote:
> This is most obviously the case for data warehouses that are doing
> lots of sequential scans of tables that don't fit in cache.
In a data warehouse, you won't have many caching effects anyway.
> But it's largely true for OLTP applications too. The more compact the
> data t
On 9/8/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Alvaro Herrera wrote:
> Statistics?
Oh, interesting.
We build this type of report for our customers:
http://pgfouine.projects.postgresql.org/reports/sample_hourly.html
This one is a real one.
As you can see, we cannot tell the type of every
I see that the buildfarm script seems to be running ecpg-check pretty
early in the sequence. Considering that the ecpg tests are still far
from stable, this seems to be taking away the opportunity to learn as
much as we can from a buildfarm run. Could we run the ecpg tests last?
An even better i
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Tom Lane) writes:
>> No you don't --- see recent warthog complaint. We have to filter LIBS
>> down to just the minimum.
> I'm at a loss, then.
> - If LIBS is being filtered to the minimum, then shouldn't it be
> appropriate to add i
Gregory Stark <[EMAIL PROTECTED]> writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> The thing is, 100% extra space is cheap, but the processing power for
>> making the need for that extra space go away is not.
> That's simply untrue for most applications.
Well, it's true for some and not
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I noticed when I was working on a patch quite a while back that there are
> no regression tests for large object support.
Yeah, this is bad :-(
> I am considering, and I think that in order to get a real test of the
> large objects, I would need to load
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > It is about time to run pgindent before we enter beta testing. Is this
> > weekend good for everyone?
>
> I think we should wait until the fate of the GUC patch is determined
> --- if we want to apply it, a pgindent run is going to c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It is about time to run pgindent before we enter beta testing. Is this
> weekend good for everyone?
I think we should wait until the fate of the GUC patch is determined
--- if we want to apply it, a pgindent run is going to cause some
unnecessary work,
Elein,
> I may have missed some stuff here. Obviously. For example how to divide
> and conquer the various aspects of the issues raised here. But this is a
> high, high level proposal at this time.
I'm not quite clear on what in your proposal is different from current Domain
behavior. Or are y
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > #2, I think, but I am confused if you don't know the query, how valuable
> > is the log_duration.
>
> Statistics?
Oh, interesting.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard
Bruce Momjian wrote:
> #2, I think, but I am confused if you don't know the query, how valuable
> is the log_duration.
Statistics?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---
I have started working on release notes for 8.2. I should have a draft
list by Saturday.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)
It is about time to run pgindent before we enter beta testing. Is this
weekend good for everyone?
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, except for bind, all the log output display is zero cost, just a
> > printf(), as I remember. The only cost that is significant, I think, is
> > the timing of the query, and that is happening for all the setttings
> > discussed.
On 9/8/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I think his basic complaint is that doing the full logging pushup for
even short-duration queries is too expensive, and that logging only the
duration and not the query text or parameters makes a significant speed
difference. I'm not at all sure tha
As many of you know I've been contemplating the implementation
of Domains and subtypes.
DISCLAIMER: This is a proposal only. The actual work needs to
be picked up by someone in a better place to work on the code
than I am. For various reasons, I can only be an active reference
and tester on t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, except for bind, all the log output display is zero cost, just a
> printf(), as I remember. The only cost that is significant, I think, is
> the timing of the query, and that is happening for all the setttings
> discussed.
On a machine with slow g
[EMAIL PROTECTED] (Jeff Davis) writes:
> On Wed, 2006-09-06 at 22:12 -0400, Christopher Browne wrote:
>
>> > Can you elaborate a little? Which filesystems have been problematic?
>> > Which filesystems are you more confident in?
>>
>> Well, more or less *all* of them, on AMD-64/Linux.
>>
>> The "p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > If you are using an external tool, can't you just restrict what you
> > display based on the logged duration?
>
> I think his basic complaint is that doing the full logging pushup for
> even short-duration queries is too expensive, an
On 9/8/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
If you are using an external tool, can't you just restrict what you
display based on the logged duration?
It's not a matter of having too much information in our reports (the
more information I have, the happier I am :)). It's a matter of
slow
Bruce Momjian <[EMAIL PROTECTED]> writes:
> If you are using an external tool, can't you just restrict what you
> display based on the logged duration?
I think his basic complaint is that doing the full logging pushup for
even short-duration queries is too expensive, and that logging only the
dura
Guillaume Smet wrote:
> On 9/8/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I don't find this very persuasive --- it sounds awfully messy, and in
> > fact isn't that exactly the old behavior we got rid of because no one
> > could understand it?
>
> I gave real use cases and we use it every day. It
Gregory Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > I think it would be good to see if we can extend the varlena data types
> > to support a shorter header for storing short byte values. Looking at
> > the header now we have:
>
> This isn't the first time we've been down that
On 9/8/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I don't find this very persuasive --- it sounds awfully messy, and in
fact isn't that exactly the old behavior we got rid of because no one
could understand it?
I gave real use cases and we use it every day. It really helps us as a
PostgreSQL hosti
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
>> In Plauger's _The Standard C Library_ (1992) on p 335 is an excerpt
>> from the standard (I think). At the end of a section entitled
>> "7.10.1.4 The strtod function" is the following: "If the correct
>> value would cause underflow, ze
Tom,
> I don't find this very persuasive --- it sounds awfully messy, and in
> fact isn't that exactly the old behavior we got rid of because no one
> could understand it?
Well, we want analogous functionality. We could stand to have it
named/organized differently. But maybe we should hold t
On Thu, Sep 07, 2006 at 06:06:51PM -0400, Tom Lane wrote:
> "Guillaume Smet" <[EMAIL PROTECTED]> writes:
> > I mean:
> > log_duration = on
> > log_min_duration_statement = 500
> > would log only duration for queries faster than 500 ms and
> > duration + query text for queries slower than 500ms (we
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> I mean:
> log_duration = on
> log_min_duration_statement = 500
> would log only duration for queries faster than 500 ms and duration +
> query text for queries slower than 500ms (we can easily avoid
> redundancy).
I don't find this very persuasive ---
Tom,
On 9/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
AFAICS, there is absolutely no difference anymore between turning
log_duration ON and setting log_min_duration_statement to zero.
ISTM that having the two redundant GUC settings is just confusing,
and we should remove log_duration to simplify t
Gregory Stark wrote:
> By my count postgres would use 154 bytes for this record. Whereas in
> fact there's no need for it to take more than 87 bytes. Almost 100%
> overhead for varattlen headers and the padding they necessitate.
The thing is, 100% extra space is cheap, but the processing power for
AFAICS, there is absolutely no difference anymore between turning
log_duration ON and setting log_min_duration_statement to zero.
ISTM that having the two redundant GUC settings is just confusing,
and we should remove log_duration to simplify things.
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it would be good to see if we can extend the varlena data types
> to support a shorter header for storing short byte values. Looking at
> the header now we have:
This isn't the first time we've been down that route. There were some
extensive di
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
> > By my count postgres would use 154 bytes for this record. Whereas in
> > fact there's no need for it to take more than 87 bytes. Almost 100%
> > overhead for varattlen headers and the padding they necessitate.
>
> The thing
Martijn van Oosterhout writes:
> On Thu, Sep 07, 2006 at 03:38:10PM +0100, Gregory Stark wrote:
> > Well I for one would be pretty unhappy if ICU were integrated. It seems
> > like a
> > whole pile of code and complexity for no particular gain. The standard i18n
> > support with a few extensions
everything should be back up and running ... vServer is now running on our
newest, 64bit HP server with FreeBSD 6.x ...
On Wed, 6 Sep 2006, Marc G. Fournier wrote:
On Mon, 4 Sep 2006, Dave Page wrote:
My understanding is that Gborg is being recovered from backup as I type. I
also understan
On Sun, Sep 03, 2006 at 09:18:00AM +0200, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > http://pgbugs.commandprompt.com (still need to configure email).
>
> Thank you for that.
>
> I think an issue tracking system for patches and such may need to be
> distinct from a bug-tracking system s
On Sat, Sep 02, 2006 at 06:31:51PM +0100, Dave Page wrote:
> > BTW, another "output" thing you might consider is "having draft release
> > notes ready-to-go on demand". Currently, Bruce prepares the release
> > notes on the basis of a very tedious scan of the CVS commit logs.
> > If this sort of s
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Well, it's taken us the full month to get this far through the queue, so
> >> I'd sure like to have more people on board reviewing next time. Alvaro
> >> helped but I miss Neil Conway, and some other people have h
On 7/9/06 15:34, "Dave Cramer" <[EMAIL PROTECTED]> wrote:
>> I can do so for jdbc if you like? If so, what are the project names
>> on each site?
>
> on gborg, the project is pgjdbc
> on pgfoundry the project is jdbc
Hi Dave,
I've setup a cron job to sync pgFoundry to Gborg every hour at hal
Peter Eisentraut wrote:
> Gregory Stark wrote:
> > By my count postgres would use 154 bytes for this record. Whereas in
> > fact there's no need for it to take more than 87 bytes. Almost 100%
> > overhead for varattlen headers and the padding they necessitate.
>
> The thing is, 100% extra space is
On Wed, 2006-09-06 at 22:12 -0400, Christopher Browne wrote:
> > Can you elaborate a little? Which filesystems have been problematic?
> > Which filesystems are you more confident in?
>
> Well, more or less *all* of them, on AMD-64/Linux.
>
> The "pulling the fibrechannel cable" test blew them al
On Tue, Sep 05, 2006 at 10:17:15AM +0400, Victor Wagner wrote:
> It's a pity that it's to late for patch to get into 8.2.
> It means that during all 8.2 lifecycle we'll have to maintain this patch
> separately.
Hmm? After 8.2 releases, if it's ready, it will go straight into CVS at
which point it'
As part of our ongoing research into Postgres performance and
scalability, we recently downloaded version 8.2 from CVS and we wanted
to pass on some observations.
When comparing 8.2 against 8.1.4, we see that there is roughly a 20%
increase in throughput. We credit most of this improvement to the
Tom Lane wrote:
>> I have realized that my modifications in configure.in and
>> src/interfaces/libpq/Makefile to link libpq against
>> OpenLDAP are buggy.
>>
>> Here is a proposed patch to fix it.
[...]
>> # The backend doesn't need everything that's in LIBS, however
>> ! LIBS := $(filter-out -
At 2006-09-05 05:47:58 -, [EMAIL PROTECTED] wrote:
>
> that difficulty no longer exists now that Abhijit has posted his
> clean-room rewrite (look for "otherlock" in -patches). Perhaps he
> would be prepared to turn that into a patch against the core...
Absolutely. Just tell me where it should
Alvaro Herrera wrote:
Joshua D. Drake wrote:
It does not mean all those features are useful, they definitely are. I
am just trying to look at it from at:
WHIZ* BANG* POW* perspective.
Holy crap, Batman! This database can do
INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and tha
On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > This has been saved for the 8.3 release:
> > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >
> > This version was withdrawn by the author for rework, no?
>
> R
I noticed when I was working on a patch quite a while back that there are
no regression tests for large object support. I know, large objects
are not the most sexy part of the code-base, and I think they tend to be
ignored/forgotten most of the time. Which IMHO is all the more reason
they should
On Thu, Sep 07, 2006 at 03:38:10PM +0100, Gregory Stark wrote:
> Well I for one would be pretty unhappy if ICU were integrated. It seems like a
> whole pile of code and complexity for no particular gain. The standard i18n
> support with a few extensions (namely strcoll_l) seems to be adequate for u
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I happened to notice that the recently added code to log Bind-message
> >> parameters was printing garbage into my log. On investigation it turned
> >> out to be trying to print an already-pfree'd string. That's
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I happened to notice that the recently added code to log Bind-message
>> parameters was printing garbage into my log. On investigation it turned
>> out to be trying to print an already-pfree'd string. That's fixable,
> Uh, can you sh
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Wed, 6 Sep 2006, Tom Lane wrote:
>> It's somewhat urgent to address this now, because pg_timezonenames is
>> sitting on the obvious name for such a view, and once we release 8.2
>> we won't be able to change it. On reflection I think the existing view
Tom Lane <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout writes:
>> On Thu, Sep 07, 2006 at 11:57:26AM +0100, Gregory Stark wrote:
>>> Just brain storming here. But what happens if we make Datum
>>> 2*sizeof(pointer)
>>> and stored the typmod and/or attlen in it?
>
>> The fundamental proper
Martijn van Oosterhout writes:
> On Thu, Sep 07, 2006 at 01:27:01PM +0100, Gregory Stark wrote:
>> ... If you look again at the columns in my example you'll
>> see none of them are appropriate targets for i18n anyways. They're all codes
>> and even numbers.
>
> Which begs the question of why they
Dave,
On 7-Sep-06, at 10:32 AM, Dave Page wrote:
-Original Message-
From: "Dave Cramer" <[EMAIL PROTECTED]>
To: "PostgreSQL-development"
Sent: 07/09/06 12:48
Subject: [HACKERS] getting access to gborg, specifically the jdbc
CVS files
In order to move to pgfoundry I need the CVS r
-Original Message-
From: "Dave Cramer" <[EMAIL PROTECTED]>
To: "PostgreSQL-development"
Sent: 07/09/06 12:48
Subject: [HACKERS] getting access to gborg, specifically the jdbc CVS files
> In order to move to pgfoundry I need the CVS repository. I can get it
> myself if I can login to g
Martijn van Oosterhout writes:
> On Thu, Sep 07, 2006 at 11:57:26AM +0100, Gregory Stark wrote:
>> Just brain storming here. But what happens if we make Datum 2*sizeof(pointer)
>> and stored the typmod and/or attlen in it?
> The fundamental property of a Datum is that you can pass it by value to
On Thu, 2006-09-07 at 14:46 +0200, Martijn van Oosterhout wrote:
> On Thu, Sep 07, 2006 at 01:27:21PM +0200, Gevik Babakhani wrote:
> > To my opinion only some of relational/compare operations like == and !=
> > apply to such values. comparing guid >= guid or md5 < md5 is also
> > meaningless.
>
>
On 9/7/06, Nimesh Satam <[EMAIL PROTECTED]> wrote:
We also noticed that the database slow downs heavily at a particular
time..Can you suggest any tools which will help in diagnosing the root cause
behiond the data load.
possible checkpoint? poorly formulated query? it could be any number
of t
On Thu, Sep 07, 2006 at 01:27:01PM +0100, Gregory Stark wrote:
> ... If you look again at the columns in my example you'll
> see none of them are appropriate targets for i18n anyways. They're all codes
> and even numbers.
Which begs the question of why they don't store the numbers in numeric
colum
On Thu, Sep 07, 2006 at 01:27:21PM +0200, Gevik Babakhani wrote:
> To my opinion only some of relational/compare operations like == and !=
> apply to such values. comparing guid >= guid or md5 < md5 is also
> meaningless.
> 4. GUID type must have the ability to be indexed, grouped, ordered,
> DI
> >> In the CVS version there is a table with this information:
> >> http://developer.postgresql.org/pgdocs/postgres/view-pg-
> timezonenames
> >> .html
> >
> > Actually, what that view gives you is timezone offset
> abbreviations,
> > not the full zone names that you could use with SET TIME ZONE.
Martijn van Oosterhout writes:
> The fundamental property of a Datum is that you can pass it by value to
> a C function. This generally means it has to fit in a register. On the
> whole, the CPU register size is the same as the pointer size, so
> 2*sizeof(pointer) is unlikely to fit...
Not havi
On Thu, Sep 07, 2006 at 01:11:49PM +0100, Gregory Stark wrote:
>
> Martijn van Oosterhout writes:
>
> > The fundamental property of a Datum is that you can pass it by value to
> > a C function. This generally means it has to fit in a register. On the
> > whole, the CPU register size is the same
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Are you sure? Perhaps you are assuming that a char(1) field can be made
> to be fixed-length; this is not the case (consider utf-8 for example).
Well that could still be fixed length, it would just be a longer fixed length.
(In theory it would hav
I realize this isn't the forum for this, but it's the closest thing
to it.
In order to move to pgfoundry I need the CVS repository. I can get it
myself if I can login to gborg, or can someone tar it up and put it
somewhere ?
Dave
---(end of broadcast)-
On 2006-09-07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Consider this real table definition I found in a few moments searching for
> schemas on google:
[snip table with lots of fixed-length char fields]
>
> By my count postgres would use 154 bytes for this record. Whereas in fact
> there's no nee
On Wed, 2006-09-06 at 17:05 -0400, [EMAIL PROTECTED] wrote:
> The UUID type itself has value, however, the value it provides is
> limited. Generation of a UUID doesn't have to occur with the database.
> The application inserting the row can generate the UUID. The UUID type
> itself has limited val
On Thu, Sep 07, 2006 at 11:57:26AM +0100, Gregory Stark wrote:
> Just brain storming here. But what happens if we make Datum 2*sizeof(pointer)
> and stored the typmod and/or attlen in it?
The fundamental property of a Datum is that you can pass it by value to
a C function. This generally means it
Gregory Stark <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout writes:
>
>> So you end up storing the typmod in the Datum itself, which brings you
>> right back to varlena.
>
> Not really since the Datum doesn't actually end up on disk in the case of
> pass-by-reference.
Just brain storming
Martijn van Oosterhout writes:
> So you end up storing the typmod in the Datum itself, which brings you
> right back to varlena.
Not really since the Datum doesn't actually end up on disk in the case of
pass-by-reference.
which leads us to:
> Well, the root of the problem depends on your persp
Hi!..
I noticed that the age of template0 is increasing very rapidly..Can you please let me know how we can control this and what causes such problems.
We also noticed that the database slow downs heavily at a particular time..Can you suggest any tools which will help in diagnosing the ro
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Yes I am fully aware of that. I am only relaying what the customer said.
Yeah sorry, I guess what I sent was pretty obvious to you. I should stop
confusing -general with -hackers :)
--
Gregory Stark
EnterpriseDB http://www.enterprise
On Wed, Sep 06, 2006 at 05:05:47PM -0400, [EMAIL PROTECTED] wrote:
> 2) Create semi-generic types with common bitlengths. Associated
>functions work on these semi-generic types. No overhead.
>- hexstring128, hexstring160, ...
>
> 3) Create a new bytea type that has asci
> Although I don't have a clear opinion myself, I sometimes read on this list
> that people are using prepared statements to get safe, stable plans, i.e.
> plans that don't depend on the specific parameter input.
I definitely want the possibility of getting stable plans. That's only
possible if
77 matches
Mail list logo
