I'm not sure how important these changes are, but perhaps we'll find fsync
faster than O_SYNC on linux 2.6.6 where O_SYNC was faster before?
[EMAIL PROTECTED]
[PATCH] ext3 fsync() and fdatasync() speedup
ext3's fsync/fdatasync implementation is currently syncing the
This patch also looks relevant to Postgres for two reasons.
This part seems like it might expose some bugs that otherwise might have
remained hidden:
This affects I/O scheduling potentially quite significantly. It is no
longer the case that the kernel will submit pages for
Just some fixups to a couple contrib directories I was trying out.
. replace CREATE OR REPLACE AGGREGATE with a separate DROP and CREATE
. add DROP for all CREATE OPERATORs
. use IMMUTABLE and STRICT instead of WITH (isStrict)
. add IMMUTABLE and STRICT to int_array_aggregate's accumulator
It seems when you create a new table with the references syntax the
constraint is created with a dependency specifically on a primary key
constraint on the target table.
However when you alter a table to add a foreign key constraint the constraint
is added with a dependency on any unique index
is correct. If it does then it can get the EXPLAIN results.
This might also let you run with EXPLAIN ANALYZE instrumentation but still get
the regular query results. Since the explain analyze results would still be
available out of band.
--
Gregory Stark
T + 514 938 2456
---(end
but that only
works because the rewritten query has an explicit ORDER BY clause.
That's about as far as I've thought about it. At the time I thought it would
likely be too hard for a first project. I suspect it's too hard for a second
project for that matter.
--
Gregory Stark
EnterpriseDB
of pgxs is precisely to find the correct locations for
these files. If it only works with standard locations then we could just hard
code them in Makefiles. So I'm pretty sure this is supposed to work.
What could I be doing wrong?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
to be reassured that his job is making progress and isn't years away from
finishing.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
to notify the user if they're trying to run
something that will be committed automatically and implicit BEGIN which starts
a new transaction but only the next time a transactional command is run.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end
of the standard data types.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
is generally
encouraged.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
if there are any left when it's done.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's
refer to what we do with CLUSTER ?
I'd really love to be able to CLUSTER a table with ALLOW WRITE ACCESS.
It's hard for me to tell from this handbook but it sort of seems like what
you're looking for is IN PLACE for which the default is ALLOW WRITE ACCESS.
--
Gregory Stark
EnterpriseDB
Martijn van Oosterhout kleptog@svana.org writes:
My main problem with the kibi, mibi, etc is that they're basically
unknown.
Frankly the main problem is that they're idiotic.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end
Yippee!
---BeginMessage---
Log Message:
---
Aggregate functions now support multiple input arguments.
...
Original patch by Sergey Koposov; review, documentation, simple regression
tests, pg_dump and psql support by moi.
---End Message---
--
Gregory Stark
EnterpriseDB
distributed hash tables.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
:) So, for example if for someone wanted to
have a persistent Oracle connection they could not open it pre-fork at library
load time but they might want to open it immediately after the fork rather
than when it's first used.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Joshua D. Drake [EMAIL PROTECTED] writes:
Those responsibilities include better communication, feature tracking and
milestones...
Wow, if we had all those we could have as efficient a release-engineering
process as Mozilla!
---(end of
that aren't have their own managers to report to already and their own
timelines and other responsibilities to deal with. They're not being paid to
meet yours.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
space.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
)
)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
of plans with one plan for each query
on a session start not one for each execution.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
with extra process that we aren't already doing anyways.
RT can be set up similarly but I'm not sure how much work it would take to
make it as seamless. Debbugs has the advantage of working that way pretty much
out of the box.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
) and numeric(x,y)? Would it let us store
those as fixed sized data types?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
don't know how easy it is
to hack in filters like that.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
comment on a bug at the same time one stomps on the others
changes?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org
]
Can you please put the patch up somewhere so people can see what's involved?
I'll send it to pgsql-patches.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
uniqueness implicitly assumes
the new tuple is live, and without any lock on the tuple you can't
promise that.
No wait. It's still live according to my snapshot. How could it be possible
for a single snapshot to see two different versions of the same tuple as live?
--
Gregory Stark
things inside a command explicitly billed as
concurrent strikes me as undesirable.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I was also considering going ahead and implementing Hannu's ALTER INDEX SET
UNIQUE too.
Don't waste your time, when we don't have an algorithm that would make
it work. It's too late for 8.2 anyway...
Oh, I think
;
n-idxname = $4;
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
in the
control flag whenever you open a data file.
That might be too expensive though I don't see data files getting opened all
that frequently. You could do the same thing for free by putting the tag in
the file names though.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
in English, it would be read as
CREATE CONCURRENTLY, INDEX ii.
That doesn't sound like English at all to me.
Fwiw, I think the best option was what Tom did. The gotcha I tripped on seems
pretty minor to me.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
on for most of their daily
use. Being able to double check the results of my ad-hoc updates before
committing them saved me more headaches than I can count with Oracle.
Autocommit off only became practical for interactive use with postgres when
savepoints showed up.
--
Gregory Stark
the first one's
phase 2 finished.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
that they're
living on their own without support from other postgres people like having a
separate domain does.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space
that it doesn't seem like a concern.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
= MaxHeapTuplesPerPage;
+ }
vacrelstats-num_dead_tuples = 0;
vacrelstats-max_dead_tuples = (int) maxtuples;
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9
to have
to reconfigure your network to allow connections on different ports.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose
control exactly when plans could change.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[EMAIL PROTECTED] writes:
Does Oracle automatically regenerate prepared plans on occasion?
Not due to statistics changes, only if your schema changes.
(caveat: I last used Oracle back at 8i)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Let's verify that. JDBC and PL/pgSQL have been mentioned.
The JDBC documentation merely contains statements of the sort A SQL
statement with or without IN parameters can be pre-compiled and stored
in a PreparedStatement
Martijn van Oosterhout kleptog@svana.org writes:
Then you would be going very much against the user's expectations.
Driver interfaces expose very clearly to the user an explicit interface to
prepare and execute a query separately. What your proposing is to go behind
the user's back
exactly what I did). a
The machine has plenty of RAM and isn't swapping or running any other
services.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map
: performsort done: CPU 0.00s/1.99u sec elapsed 2.00 sec
LOG: internal sort ended, 11919 KB used: CPU 0.00s/2.03u sec elapsed 2.04 sec
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget
*believe* how simple you have to keep these things in processor
architecture. :-)
I think the slow part is trying to figure out whether to count the current
call as a hit or a miss. How do you determine whether the plan you're running
is the best plan without replanning the query?
--
Gregory
I'm getting paranoid that perhaps
this is just a bug in my hacked up copy of this code. I can't see how that
could be but I'll try reproducing it with stock CVS Postgres.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
it would give me a hell of a lot more confidence if people could say they've
been in the CVS version for months and nobody's had problems with them than to
be told they were reviewed by one person three weeks ago and nobody else has
had much of a chance to use it.
--
Gregory Stark
EnterpriseDB
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, no, it's not. We have told people till we're blue in the face
post early, post often. Now I will plead guilty to not always
having spent as much time giving feedback on draft patches as I
should've, but the process is
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
As an extreme example consider the new Linux release cycle. They have a
non-freeze period of a couple weeks, followed by months of frozen time.
Users
who want to try out new features on different hardware can do
the cached plan was correct?
So once again, does anyone know of any realistic logs that I can use for
more useful simulations?
You might look at the DBT test suite, iirc the TPCC spec it implements
intentionally mixes random queries with predictable queries.
--
Gregory Stark
EnterpriseDB
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sun, September 3, 2006 18:41, Gregory Stark wrote:
I'm confused, what exactly are you trying to predict? Whether each
parameter
will be some cached value? Or whether the cached plan was correct?
That's described in more detail in a separate
of it. But in the long run they may
be two complementary sides of the same thing.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
the development discussions. I don't see old
school unix hackers used to discussing things in email switching over to some
web based interface to replace development mailing lists.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces, I
think Tom's recent remarks relating to the 21st century were more than
apposite.
I like web interfaces well enough for the things they're good at.
Replacing e-mail is not one
- returns TRUE if left argument is a descendant of right argument (or
equal).
If you consider ltree entries to be sets containing all their children then
those sound consistent.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end
Gregory Stark [EMAIL PROTECTED] writes:
Matteo Beccati [EMAIL PROTECTED] writes:
Tom Lane ha scritto:
x @ y means x is contained in y
ltree @ ltree
If you consider ltree entries to be sets containing all their children then
those sound consistent.
Oops, sorry for the noise
it to acquire a
different lock on the same buffer but it's true that it doesn't always have to
acquire the second lock.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9
we have it for int8.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
) \
)) \
)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Martijn van Oosterhout kleptog@svana.org writes:
attlen -2 is used for cstring (null terminated strings).
Hope this helps,
Well that's what the code I quoted indicates. But when do we ever store a
cstring in a tuple? Certainly I can't find any standard data types that use
it.
--
Gregory
could summarize the root of the problem and explain exactly what circumstances
the typmod is unavailable. I would summarize the responses and put them up on
the wiki.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
cause what results. Describing them in shorthand like if connection attempts
are made is leading to a lot of speculation instead of systematic deductions.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
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
refers to.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
Gregory Stark [EMAIL PROTECTED] writes:
Martijn van Oosterhout kleptog@svana.org 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
locale with ascii encoding.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
to fit...
Not having it fit in a register might impact performance but it certainly
isn't a requirement. You can pass whole structs by value in modern C. (And by
modern here I don't mean C99, this has been supported since before ANSI and is
required by *C89*).
--
Gregory Stark
EnterpriseDB
Martijn van Oosterhout kleptog@svana.org 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
Tom Lane [EMAIL PROTECTED] writes:
Martijn van Oosterhout kleptog@svana.org 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
Martijn van Oosterhout kleptog@svana.org 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
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 is, 100
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
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 a whole word
Peter Eisentraut [EMAIL PROTECTED] writes:
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
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
But that won't help in the example you posted upthread, because
char(N) is not fixed-length.
Sure it is because any sane database--certainly any sane database
using char(N)--is in C locale anyways.
This matter
Gregory Stark [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
But that won't help in the example you posted upthread, because
char(N) is not fixed-length.
Sure it is because any sane database--certainly any sane database
using char
feel still I
am missing some information after observing extracted information abt buffer
replacement.
Try
explain select ...
The output may be enlightening.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
to take care of
this problem? I was looking for a more general solution.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
table creation sort the fields to minimize padding. It won't always be perfect
but sometimes it could help quite a bit. It also wouldn't help much if you
start altering the table afterward but even then the next time you pg_dump and
reload you'll get a more efficient layout.
--
Gregory Stark
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The performance costs of that seem pretty daunting, however, especially when
you reflect that simply stepping over a varlena field would require
memcpy'ing its length word to someplace.
I think if you give up
: yes that's the way Postgres works and if
you want to report all the violations together you'll have to check them
yourself.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading
Tom Lane [EMAIL PROTECTED] writes:
Stephan Szabo [EMAIL PROTECTED] writes:
I think if we were going to do this that all the constraint violations for
unique, not null, check and foreign keys should be handled similarly, so
we'd probably want something more general than just a way for the
length headers because
even though it would never occur on disk it would be necessary to for the
uncompressed and/or detoasted data.
In your scheme what would PG_GETARG_TEXT() give you if the data was detoasted
to larger than 16k?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I'm a bit confused by this and how it would be handled in your sketch. I
assumed we needed a bit pattern dedicated to 4-byte length headers because
even though it would never occur on disk it would be necessary
is an implicit cast.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:../reference.ced
sgml-exposed-tags:nil
sgml-local-catalogs:/usr/lib/sgml/catalog
sgml-local-ecat-files:nil
End:
--
--
Gregory
encodings
aside from ascii. We would probably still need a CHAR(2) data type too where
the overhead is still 50%.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
semantics to match
CHAR(1) or adding a separate type instead.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
In any case it seems a bit backwards to me. Wouldn't it be better to
preserve bits in the case of short length words where they're precious
rather than long ones? If we make 0xxx the 1-byte case it means ...
Well
to suggest going back and looking for *more* space
savings in numeric. I had assumed this first step had gone in long ago.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our
could just use an implementation that's better.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
At first I meant that as a reductio ad absurdum argument, but, uh,
come to think of it why *do* we have our own arbitrary precision
library? Is there any particular reason we can't use one of the
existing binary
postgresql-common57 manager for PostgreSQL database cl
postgresql-8.1 recommends no packages.
-- no debconf information
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't
it would take a large table to make that possible I think).
In short I think what's needed is someone to review a lot of different stats
metrics for correlation and clustering and do some analysis of how each would
be useful for cost modelling.
--
Gregory Stark
EnterpriseDB http
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Well char doesn't have quite the same semantics as CHAR(1). If that's the
consensus though then I can work on either fixing char semantics to match
CHAR(1) or adding a separate type instead.
What semantics?
The main bit
in the past but I wouldn't be surprised.
Consider that the bug being fixed in the point release may well be a bug in
WAL log formatting.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain
to recognise the broken WAL records and
process them correctly rather than simply generate corrected records. That
could be quite a burden.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't
format changes. In that light you're suggesting extending the policy which I
guess I just thought should be done explicitly rather than making policy by
accident.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
1 - 100 of 1641 matches
Mail list logo
