Zdenek Kotala wrote:
PostgreSQL stores all table's external data in one TOAST table and
stored data does not contains any clue about datatype. When postgreSQL
reads TOSTEed value then there is not possible detect what type it is
and perform varlena conversion on composite datatypes or arrays.
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast
chunk size more flexible.
Attached patch add three new columns into pg_class
relblocksize - which is always BLCKSZ. I put it there for fullness, but
Zdenek Kotala wrote:
The problem what I need to solve is how to handle different TOAST chunk
size which becomes with upgrade. if you insert new record into TOAST
table it will be created on the new page which has different max chunk
size, because it depends on page header size. It means that
ITAGAKI Takahiro napsal(a):
Zdenek Kotala [EMAIL PROTECTED] wrote:
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast
chunk size more flexible.
I agree that flexible toast threshold is useful, but I have
several questions in your implementations.
relblocksize -
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
EXPLAIN EXECUTE p('2008-07-01');
-
Append
- Result
One-Time Filter: (('2008-01-01' = $1) AND ($1 '2009-01-01'))
- Index Scan on test_2008_t_key
Dear All,
I took a look at the source code for hash join this morning and I realized
that the block nested loop join is somewhat similar to that.
Thanks for the discussions.
Bramandia R.
On Fri, Oct 10, 2008 at 8:19 PM, Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED]
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Not all chunks need to be the same size. We do currently require that,
but AFAICS it's only because that allows random access to a given
offset within a datum. That's of course nice, but I think we could
live without it.
Good point. I
Heikki Linnakangas [EMAIL PROTECTED] writes:
No, I was thinking of something along the lines of:
INFO: clustering public.my_c
INFO: complete, was 33%, now 100% clustered
The only such measure that we have is the correlation, which isn't very
good anyway, so I'm not sure if that's
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The problem what I need to solve is how to handle different TOAST
chunk size which becomes with upgrade. if you insert new record into
TOAST table it will be created on the new page which has different max
chunk size, because it depends on
Hi,
Josh Berkus wrote:
So it sounds like intagg is still in use/development. But ... is it
more of an example, or is it useful as a type/function in production?
We use it in production for quite remarkable speedups of operations on
int4[].
Having reviewed the last commit fest's intagg patch
On Wed, Oct 8, 2008 at 4:27 PM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
* Instead of the above, we could try to make
ROW(some columns) = ANY (array variable)
work. This is shorter than the
Gregory Stark [EMAIL PROTECTED] writes:
This file was moved lo, these many years
Done ... but why did your patch change oidjoins.out and not oidjoins.sql?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Merlin Moncure [EMAIL PROTECTED] writes:
The record ops work as promised. IMO this patch stands in its own
merits with or without the CTE changes. I played around with it and
noticed a couple of oddities:
select foo = foo from foo; --works
but
select distinct foo from foo; --yields
Heikki Linnakangas napsal(a):
It occurs to me that instead of storing a chunk id, we could store a
byte offset of the chunk. That would allow random access even if every
chunk was of different size. You probably don't want any new changes you
need to deal with in the upgrade, though :-).
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Besides, the read all formats approach wouldn't really avoid it
either. If you passed a toasted datum to a function, when the
function needs to detoast it, detoast_datum still wouldn't know
whether the datum is
I wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
select foo from foo order by foo;
ERROR: could not identify an ordering operator for type foo
Yeah, these are because of the incomplete handling of named record
types. I'm not sure how far we want to go in that direction.
On looking
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
This file was moved lo, these many years
Done ... but why did your patch change oidjoins.out and not oidjoins.sql?
I had other changes in my tree, I just diffed the files individually rather
than doing a cvs diff
--
This file was moved lo, these many years
diff --git a/src/tools/findoidjoins/make_oidjoins_check
b/src/tools/findoidjoins/make_oidjoins_check
index 5061634..9c6b850 100755
--- a/src/tools/findoidjoins/make_oidjoins_check
+++ b/src/tools/findoidjoins/make_oidjoins_check
@@ -54,7 +54,7 @@ $AWK
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
No, I was thinking of something along the lines of:
INFO: clustering public.my_c
INFO: complete, was 33%, now 100% clustered
The only such measure that we have is the
On Oct 10, 2008, at 3:40 PM, Robert Haas wrote:
I dislike all own creatures - because nobody will understand so do
some wrong thing - using non standard formats is bad thing. So
it's is
necessary, then who need it then he found it on pgfoundry. But why
smudge core?
I'm opposed to smudging
I have added a link at the bottom of the page.
All the info on how to use Eclipse with Postgres can be found at
http://wiki.postgresql.org/wiki/Working_with_Eclipse
All suggestions and comments are welcome of course.
Emmanuel
Looks great, thanks!
--Chris
--
Sent via pgsql-hackers mailing
Jim Cox wrote:
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
No, I was thinking of something along the lines of:
INFO: clustering public.my_c
INFO: complete, was 33%, now 100% clustered
The only such measure that we have is
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
PostgreSQL stores all table's external data in one TOAST table and
stored data does not contains any clue about datatype. When postgreSQL
reads TOSTEed value then there is not possible detect what type it is
and perform varlena conversion on
On Fri, 2008-10-10 at 09:41 -0400, Tom Lane wrote:
So I was looking for other omissions in utility.c, and I noticed that
check_xact_readonly() doesn't reject CLUSTER, REINDEX, or VACUUM.
Now the notion of read only that we're trying to enforce is pretty
weak (I think it's effectively no
Zdenek Kotala wrote:
I expect that function cannot get toast pointer. It can get only
detoasted attributes. Correct me if I'm wrong.
A function is passed a raw datum, which can be toasted. Now, practically
all functions call one of the PG_GETARG_* macros that detoast the datum
before doing
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Besides, the read all formats approach wouldn't really avoid it
either. If you passed a toasted datum to a function, when the function
needs to detoast it, detoast_datum still wouldn't know whether the
datum is in old or new format. You'd
Hello,
Constraint exclusion (CE) is very useful for partitioned tables,
but prepared statements interfere with CE if the parameter
contains partition keys, because CE is a planner-time optimization
but the actual parameters are given at executor-time.
I have an idea to use constraint exclusion
Jim Cox wrote:
On Fri, Oct 10, 2008 at 10:23 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Kevin Grittner wrote:
Jim Cox [EMAIL PROTECTED] wrote:
if present an INFO message is generated which displays
the schema.tblname just before actual clustering is kicked off (see
example
On Oct 12, 2008, at 20:15, Joshua D. Drake wrote:
Yeah I would agree with that. I find that only real issue with
PgFoundry is the PgFoundry (aka Gforge) not the quality of the
projects being hosted.
The other thing that could use some love is searching for projects.
Google doesn't rank
Howdy,
Not sure if PostgreSQL uses time_t, but if so, this project provides
useful code (a drop-in replacement for time.h) to address the 2038 bug
on 32-bit platforms.
http://code.google.com/p/y2038/
Useful for PostgreSQL?
Best,
David
--
Sent via pgsql-hackers mailing list
David E. Wheeler [EMAIL PROTECTED] writes:
Not sure if PostgreSQL uses time_t,
We got rid of that some time ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Oct 13, 2008, at 11:01, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Not sure if PostgreSQL uses time_t,
We got rid of that some time ago.
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
Thanks,
David
--
David E. Wheeler [EMAIL PROTECTED] writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Oct 13, 2008, at 11:13, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you'd say that. See:
David E. Wheeler napsal(a):
On Oct 13, 2008, at 11:13, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you'd
David E. Wheeler wrote:
On Oct 13, 2008, at 11:13, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you'd say
On Oct 13, 2008, at 11:22, Zdenek Kotala wrote:
PostgreSQL 8.4 uses 64bit data type for time. But if you use system
timezone then you can get in trouble if system does not support
64bit zic files.
I've never noticed a problem with the TZinfo database that ships on
systems I've used. How
On Oct 13, 2008, at 11:24, Andrew Chernow wrote:
PostgreSQL doesn't use the standard time_t and time functions for
its timestamp types. Therefore, any limitations in regards to 64-
bit time_t values on 32-bit platforms don't apply; other than the
limitation Tom spoke of ... no 64-bit int.
David E. Wheeler napsal(a):
On Oct 13, 2008, at 11:22, Zdenek Kotala wrote:
PostgreSQL 8.4 uses 64bit data type for time. But if you use system
timezone then you can get in trouble if system does not support 64bit
zic files.
I've never noticed a problem with the TZinfo database that ships
Two different buildfarm machines are currently showing the same failure:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=kududt=2008-10-13%2015:30:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2008-10-13%2016:30:01
The postmaster log in each case shows
ERROR: could not
On Oct 13, 2008, at 11:37, Zdenek Kotala wrote:
when you use --with-system-tzdata and run make check on head it
fails on systemes without 64bit tzinfo support.
Oh. Is it not preferable to use the tzdata that ships with PostgreSQL?
Thanks,
David
--
Sent via pgsql-hackers mailing list
David E. Wheeler [EMAIL PROTECTED] writes:
On Oct 13, 2008, at 11:37, Zdenek Kotala wrote:
when you use --with-system-tzdata and run make check on head it
fails on systemes without 64bit tzinfo support.
Oh. Is it not preferable to use the tzdata that ships with PostgreSQL?
Not necessarily;
On Oct 13, 2008, at 11:53, Tom Lane wrote:
Oh. Is it not preferable to use the tzdata that ships with
PostgreSQL?
Not necessarily; the system might have a more up-to-date tzdata.
Gotcha.
Generally you'd use --with-system-tzdata on a platform where you
expect
to receive routine package
On Mon, 2008-10-13 at 08:30 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
No, I was thinking of something along the lines of:
INFO: clustering public.my_c
INFO: complete, was 33%, now 100% clustered
The only such measure that we have is the correlation, which isn't
Tom Lane napsal(a):
Generally you'd use --with-system-tzdata on a platform where you expect
to receive routine package updates for the tzdata files, independently
of the Postgres release cycle. It seems reasonable to assume that
anyone currently shipping tzdata is offering 64-bit files. (But
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
select foo from foo order by foo;
ERROR: could not identify an ordering operator for type foo
Yeah, these are because of the incomplete handling of named record
types. I'm
On Oct 13, 2008, at 12:35, Zdenek Kotala wrote:
Tom Lane napsal(a):
Generally you'd use --with-system-tzdata on a platform where you
expect
to receive routine package updates for the tzdata files,
independently
of the Postgres release cycle. It seems reasonable to assume that
anyone
Hello,
We finally got around to releasing Replicator as FOSS. It is BSD
licensed and available here:
https://projects.commandprompt.com/public/replicator/wiki
(Yes it is a self signed cert, its on the list to fix).
Enjoy folks!
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since
Heikki Linnakangas [EMAIL PROTECTED] writes:
Jim Cox wrote:
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
It'd be possible to count the number of order reversals during the
indexscan, ie the number of tuples with CTID lower
I wrote:
Two different buildfarm machines are currently showing the same failure:
ERROR: could not fsync segment 0 of relation 1663/16384/29270/1: No such
file or directory
ERROR: checkpoint request failed
Some tests show that when the serial regression tests are run in a
freshly initdb'd
Gregory Stark [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Until we have a better metric for sortedness, my earlier suggestion to
print
it was probably a bad idea. If anything, should probably print the same
correlation metric that ANALYZE calculates, so that it
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I agree with that. I like the idea of printing a message though -- we should
just have it print the correlation for now and when we improve the stats
we'll
print the new metric.
Short of actually running an
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Short of actually running an ANALYZE, I'm not seeing a good way to
derive the same number it derives.
Well we could print the _old_ value at least.
+1 ... seems an appropriate amount of effort for the likely value.
Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Short of actually running an ANALYZE, I'm not seeing a good way to
derive the same number it derives.
Well we could print the _old_ value at least.
+1 ... seems an appropriate
On Mon, 13 Oct 2008, Tom Lane wrote:
I notice now that kudu and dragonfly are actually the same machine ...
could this be an OS-specific problem? Kris, has there been any
system-software change on that machine recently?
This is a VM that I haven't touched in some time. It was turned off
On Mon, 13 Oct 2008 15:34:04 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:
ccdev=# select pg_total_relation_size('DbTranImageStatus');
pg_total_relation_size
253952
(1 row)
ccdev=# cluster DbTranImageStatus;
CLUSTER
ccdev=# select
Greg Smith wrote:
The drives themselves, and possibly the OS and disk controller, are all
running read-ahead algorithms to accelerate this case. In fact, this
*exact* case for the Linux read-ahead stuff that just went mainline
recently: http://kerneltrap.org/node/6642
Apparently only the
Magnus Hagander wrote:
Second, once I've successfully built and installed postgres, I run into
a bigger problem. When using initdb, I get this error:
creating template1 database in c:/Data/postgres30/base/1 ... FATAL:
could not create shared memory segment: 5
DETAIL: Failed system call was
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to apply the patch with binary-coercibility adjustments
and not try to turn RECORD or RECORD[] into full-fledged polymorphic
types. It's not immediately clear what the use
Hitoshi Harada wrote:
I made up my mind to scratch former window functions and redesigned
completely new execution model, based on the discussion with Heikki.
Attached is the v06 against HEAD today.
http://umitanuki.net/pgsql/wfv06/design.html
First off, fantastic work!
In my eyes this and WITH
Tom Lane escribió:
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to apply the patch with binary-coercibility adjustments
and not try to turn RECORD or RECORD[] into full-fledged polymorphic
types. It's not
2008/10/14 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada wrote:
I made up my mind to scratch former window functions and redesigned
completely new execution model, based on the discussion with Heikki.
Attached is the v06 against HEAD today.
http://umitanuki.net/pgsql/wfv06/design.html
First
Hitoshi Harada [EMAIL PROTECTED] writes:
I agree I need to work on that. Also from the spec, RESPECT NULLS /
IGNORE NULLS may be specified but not supported yet. This syntax
specification is out of the postgres general function call so I wonder
if those functions are treated specially or not.
ISTM that xact_desc routines do not work properly when called with
WAL_DEBUG enabled from XLogInsert().
LOG: INSERT @ 0/3740978: prev 0/3740938; xid 5699: Transaction -
commit: 2008-10-14 03:14:14.866437+01; subxacts: 10447936 0
STATEMENT: commit;
LOG: INSERT @ 0/37409F0: prev 0/37409B0; xid
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that xact_desc routines do not work properly when called with
WAL_DEBUG enabled from XLogInsert().
Well, now that you mention it, that code is utterly, completely broken,
and always has been. It's passing only the first rdata-chunk of the WAL
record
Andrew Sullivan wrote:
On Fri, Oct 10, 2008 at 01:44:49PM +0900, KaiGai Kohei wrote:
Andrew Sullivan wrote:
I want to focus on this description, because you appear to be limiting
the problem scope tremendously here. We've moved from general
security policy for database system to security
Andres Freund wrote:
Hi,
It might be relevant for the whole discussion about inclusion of some form of
row level permissions, whatever based on, that there exist heaps of (in my
eyes conflicting) patents about row level permissions for relational
databases. I don't have any real clue
67 matches
Mail list logo
