Andrew Dunstan schrieb:
Hannes Eder wrote:
-open($D, dir /b $subdirs $spec |) || croak Could not list
$spec\n;
+open($D, cmd /c dir /b $subdirs $spec |) || croak Could not
list $spec\n;
What the heck are we doing here anyway? We should be doing this a la
Perl - calling out to dir
On Wed, May 30, 2007 at 12:09:05PM +0200, Hannes Eder wrote:
Andrew Dunstan schrieb:
Hannes Eder wrote:
-open($D, dir /b $subdirs $spec |) || croak Could not list
$spec\n;
+open($D, cmd /c dir /b $subdirs $spec |) || croak Could not
list $spec\n;
What the heck are we doing
I reran the tests with hashtext(), and created a SUMMARY.HTML chart:
http://momjian.us/expire/TOAST/
What you will see is that pushing TEXT to a TOAST column
allows quick access to non-TOAST values and single-row TOAST
values, but accessing all TOAST columns is slower than
Magnus Hagander schrieb:
Are you actually *running* the script from inside cygwin? How else does it
pick up the wrong command processor?
I run the script within cmd.exe, but cygwin´s /usr/bin directory is in
my PATH, therefor cygwin dir executable is in the PATH (/usr/bin/dir).
Instead of
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
My expectation would be, that we want to allow a toast tuple to fill a
whole page (TOAST_TUPLES_PER_PAGE = 1),
I've been wondering about that too. It certainly needs to be
experimented with, independently of TOAST_TUPLE_THRESHOLD, now that
On Wed, May 30, 2007 at 01:56:24PM +0200, Hannes Eder wrote:
Magnus Hagander schrieb:
Are you actually *running* the script from inside cygwin? How else does it
pick up the wrong command processor?
I run the script within cmd.exe, but cygwin´s /usr/bin directory is in
my PATH, therefor
Hello,
I have a question about passing parameters to a C function. Imagine the
example by PostgreSQL:
PG_FUNCTION_INFO_V1(complex_add);
Datum
complex_add(PG_FUNCTION_ARGS)
{
Complex*a = (Complex *) PG_GETARG_POINTER(0);
Complex*b = (Complex *)
On Wed, May 30, 2007 at 11:26:01AM -0300, Rodrigo Sakai wrote:
I have a question about passing parameters to a C function. Imagine the
example by PostgreSQL:
PG_FUNCTION_INFO_V1(complex_add);
But using version 1 calling convention it won't work! So, how can I pass the
'a' and 'b'
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Wed, May 30, 2007 at 11:26:01AM -0300, Rodrigo Sakai wrote:
But using version 1 calling convention it won't work! So, how can I pass the
'a' and 'b' variables in complex_add(?, ?)?
Use the DirectFunctionCalln functions in fmgr.
There are
Tom Lane [EMAIL PROTECTED] writes:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
My expectation would be, that we want to allow a toast tuple to fill a
whole page (TOAST_TUPLES_PER_PAGE = 1),
I thought that previously but then I started thinking maybe that's not true.
Picture
Greetings,
It'd be nice to have a NOTICE printed when a wait-on-lock takes longer
than a few seconds. It doesn't need to be precise and it doesn't have
to be repeated over and over, just once. Perhaps even controlled by a
GUC, though NOTICEs are generally ignored by non-interactive
Gregory Stark [EMAIL PROTECTED] writes:
Whereas if you set toast_tuples_per_page to 8k then the only option for
Postgres will be to put each datum in its own page and waste 1-3k on every
page.
No, because actually the code is designed to make the toast chunk size
just enough less than 8K that
Stephen Frost [EMAIL PROTECTED] writes:
It'd be nice to have a NOTICE printed when a wait-on-lock takes longer
than a few seconds.
It'd be relatively painless to make that happen as part of the
deadlock-check timeout function, but that's typically only a one-second
delay not a few seconds.
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
It'd be nice to have a NOTICE printed when a wait-on-lock takes longer
than a few seconds.
It'd be relatively painless to make that happen as part of the
deadlock-check timeout function, but that's typically
Does anyone actually read these?
LOG: database system was shut down at 2007-05-30 17:54:39 CEST
LOG: checkpoint record is at 0/42C4FC
LOG: redo record is at 0/42C4FC; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/593; next OID: 10820
LOG: next MultiXactId: 1; next
Tom Lane [EMAIL PROTECTED] writes:
The shorter-than-normal tuples carrying the last chunk of any particular
datum are going to result in wasted space to the extent that we can't
pack them together on a page, but that's true now. Right now, if you
have a large toasted datum, it mostly will
Whereas if you set toast_tuples_per_page to 8k then the only option
for Postgres will be to put each datum in its own page and
waste 1-3k
on every page.
No, because actually the code is designed to make the toast
chunk size just enough less than 8K that the tuples fit.
He
Just to get an opinion, which is better:
could not open transaction log file %s: %m
could not open control file %s: %m
could not open data file %s: %m
could not open temporary file %s: %m
could not open whatever file %s: %m
or just:
could not open file %s: %m
It seems to me that by the time
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It'd be relatively painless to make that happen as part of the
deadlock-check timeout function, but that's typically only a one-second
delay not a few seconds. I think it'd likely be overly chatty.
Yeah, I
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
It'd be nice to have a NOTICE printed when a wait-on-lock takes longer
than a few seconds.
It'd be relatively painless to make that happen as part of the
deadlock-check timeout
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Whereas if you set toast_tuples_per_page to 8k then the only option for
Postgres will be to put each datum in its own page and waste 1-3k on every
page.
No, because actually the code is designed to make the toast chunk size
just
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Yeah, I wouldn't want one per second.
It's not one per second, it's after one second (actually
deadlock_timeout) has elapsed since you started to sleep waiting for a
lock. If a deadlock is not detected the process won't be
Hello,
I'm trying to write a trigger on insert which should insert the row
in another
table. The table on which to insert the row should be selected at
runtime and
it is not know in advance. For example, let's say we have a table with
two columns, a date and an integer. a row is inserted
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It'd be relatively painless to make that happen as part of the
deadlock-check timeout function, but that's typically only a one-second
delay not a few seconds. I think it'd
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
AFAICT a real fix for this would involve making PQfinish() synchronous
(don't return till backend is
Peter Eisentraut wrote:
Just to get an opinion, which is better:
could not open transaction log file %s: %m
could not open control file %s: %m
could not open data file %s: %m
could not open temporary file %s: %m
could not open whatever file %s: %m
or just:
could not open file %s: %m
It seems
Tom Lane wrote:
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
AFAICT a real fix for this would involve making PQfinish() synchronous
(don't return
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
AFAICT a real fix for this would involve making PQfinish() synchronous
(don't return till backend is dead), which doesn't seem like a great
idea. However, it suddenly struck me that we could probably make most
of the problem go away
Bruce Momjian wrote:
What you will see is that pushing TEXT to a TOAST column allows quick
access to non-TOAST values and single-row TOAST values, but accessing
all TOAST columns is slower than accessing them in the heap, by a factor
of 3-18x.
Looking at the chart, it seems 512 is the proper
Tom Lane wrote:
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
AFAICT a real fix for this would involve making PQfinish() synchronous
(don't return
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, am I supposed to be running more TOAST tests? Would someone explain
what they want tested?
If you want my opinion I would say we need two tests:
1) For TOAST_TUPLE_TARGET:
We need to run the test scripts you have already for sizes that cause
Peter Eisentraut [EMAIL PROTECTED] writes:
Just to get an opinion, which is better:
could not open whatever file %s: %m
or just:
could not open file %s: %m
It seems to me that by the time you get to a file error message of this
level, the higher-level purpose of the file is pretty
Brian Hurt [EMAIL PROTECTED] writes:
Tom Lane wrote:
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
Is this a synchronization issue?
The problem is
Hi,
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
This is how it works:
- IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
bits.
It returns 5 bytes if the netmask is shorter than 32 bits.
-
Hello,
I am currently writing some curriculum on managing IO with PostgreSQL
and I keep running into the parameter checkpolint_timeout. This seems to
be incorrect as it is not really a timeout as much as an interval...
Thoughts?
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL
Joshua D. Drake wrote:
Hello,
I am currently writing some curriculum on managing IO with PostgreSQL
and I keep running into the parameter checkpolint_timeout.
*cough* checkpoint_timeout
This seems to
be incorrect as it is not really a timeout as much as an interval...
Thoughts?
Zoltan Boszormenyi wrote:
Hi,
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
This is how it works:
- IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
bits.
It returns 5 bytes if the netmask
Joshua D. Drake wrote:
Joshua D. Drake wrote:
Hello,
I am currently writing some curriculum on managing IO with PostgreSQL
and I keep running into the parameter checkpolint_timeout.
*cough* checkpoint_timeout
This seems to
be incorrect as it is not really a timeout as much as an
On Mon, 2007-28-05 at 15:24 -0400, Tom Lane wrote:
readline has much more functionality
Fair enough, that's probably a good enough reason to leave things as
they are for now.
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase your
Tom Lane [EMAIL PROTECTED] writes:
However, it suddenly struck me that we could probably make most of the
problem go away if we put that same wait into DROP DATABASE itself --- that
is, if we see other backends in the target DB, sleep for a second or two and
then recheck before erroring out.
Added to TODO:
* Consider allowing 64-bit integers to be passed by reference on 64-bit
platforms
---
Neil Conway wrote:
On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote:
(I imagine someday we'll get around to
I think that's backwards. We *are* passing them by reference, we should
be considering passing them by value.
//Magnus
Bruce Momjian wrote:
Added to TODO:
* Consider allowing 64-bit integers to be passed by reference on 64-bit
platforms
Tom,
Even if we had a semaphore of the sort you suggest, I doubt people would
want DROP DATABASE to wait indefinitely. The real question here is how
long is it reasonable for DROP DATABASE to wait before failing ...
10 to 15 seconds, I'd say. Is that going to be long enough for backends to
Magnus Hagander wrote:
I think that's backwards. We *are* passing them by reference, we should
be considering passing them by value.
Thanks, fixed.
---
//Magnus
Bruce Momjian wrote:
Added to TODO:
*
Tom Lane [EMAIL PROTECTED] writes:
A seasoned developer might only need the file name to guess what kind of
file it is, but other people could probably use the help.
I think Peter's argument is that what kind of file it is really doesn't help a
regular user. Nonetheless I agree strongly. Even
Peter Eisentraut [EMAIL PROTECTED] writes:
Does anyone actually read these?
LOG: database system was shut down at 2007-05-30 17:54:39 CEST
LOG: checkpoint record is at 0/42C4FC
LOG: redo record is at 0/42C4FC; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/593; next OID:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
I think that's backwards. We *are* passing them by reference, we should
be considering passing them by value.
Thanks, fixed.
Also, the TODO item ought to mention float4 and float8, which IMHO ought
to be changed at the same time.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
I think that's backwards. We *are* passing them by reference, we should
be considering passing them by value.
Thanks, fixed.
Also, the TODO item ought to mention float4 and float8, which IMHO ought
to be
Gregory Stark [EMAIL PROTECTED] writes:
Is there any way to tell, perhaps from the command string, that the process is
about to start exiting? What stage of exiting is it that we think the kernel
goes to lunch?
I haven't really done any detailed investigation, but I would think that
a simple
Tom Lane wrote:
Log Message:
---
Make large sequential scans and VACUUMs work in a limited-size ring of
buffers, rather than blowing out the whole shared-buffer arena. Aside from
avoiding cache spoliation, this fixes the problem that VACUUM formerly tended
to cause a WAL flush for
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
Why is this a good idea? Exposing the internal representation of a
datatype is usually bad. What will you do when we add
All,
I now have a simple test case which shows significant performance
degradation on 8.3devel for a specific query, apparenly due to an
unnecessary call to Top-N sort. I've tried to forward the test case to
the lists but the package is 3.5m, so I'm putting it on pgFoundry instead:
If you
Josh Berkus [EMAIL PROTECTED] writes:
I now have a simple test case which shows significant performance
degradation on 8.3devel for a specific query, apparenly due to an
unnecessary call to Top-N sort.
It does the right thing if t_s_symb is declared as text instead of
varchar. When it's
Josh Berkus [EMAIL PROTECTED] writes:
On Wednesday 30 May 2007 15:51, Josh Berkus wrote:
I now have a simple test case which shows significant performance
degradation on 8.3devel for a specific query, apparenly due to an
unnecessary call to Top-N sort. I've tried to forward the test case to
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
A seasoned developer might only need the file name to guess what kind of
file it is, but other people could probably use the help.
I think Peter's argument is that what kind of file it is really doesn't help a
regular user. Nonetheless
Hello,
I'm developing an application that needs a different data type. So, I have
implemented this new data type inside postgresql using C, as documentation
shows to.
Basically, the data type is a composition of two timestamps, like:
(timestamp, timestamp) and it is called 'period'.
Greg,
How recently did you check out your 8.3 tree?
It's the snapshot from 5/28, which means it was pulled from CVS on 5/27.
So, recent.
When I run it I get a bitmap index scan which I think might mean you're
suffering from the same problem Tom found and fixed a few days ago. The
planner
I tested EXTERN_TUPLES_PER_PAGE for values 4(default), 2, and 1:
4 15.596
2 15.197
1 14.6
which is basically a 3% decrease from 4-2 and 2-1. The test script
and result are here:
http://momjian.us/expire/TOAST2/
shared_buffers again was 32MB
Bruce Momjian írta:
Zoltan Boszormenyi wrote:
Hi,
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
This is how it works:
- IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
bits.
It returns 5
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
Why is this a good idea? Exposing the internal representation of a
datatype is usually bad.
I didn't
60 matches
Mail list logo
