I see... PostgreSQL wants to guess the datatype, given no clear
syntactic information, and perhaps a varchar(n) wouldn't be a valid cast
to some of the possible datatypes.
So, where x = '(1,2)' might be legal for comparing to x, but a field of
type varchar(5) might not be, as in where x = y,
If we tries to drop the table on which autovacuum is running, we have to
wait finish of the vacuum. However, the vacuuming effort goes to waste for
the table being dropped or rewritten. Meanwhile, we've already had the
autovacuum killer triggered in CREATE/DROP/RENAME DATABASE commands.
Can we
On Wed, Jun 13, 2007 at 02:12:37AM -0400, Chuck McDevitt wrote:
So, where x = '(1,2)' might be legal for comparing to x, but a field of
type varchar(5) might not be, as in where x = y, where y is type
varchar(5) containing '(1,2)'.
Normally, just about every type can be converted to or from
I was just looking at implementing some query tuning/debugging features
in pgAdmin, and was looking to use EXPLAIN output to get a list of the
base tables involved in the users' query. Unfortunately though it
doesn't include the schema name in the output which means I have no way
of telling for
Chuck McDevitt [EMAIL PROTECTED] writes:
Just a curiosity question: Why is the type of a literal '1' unknown
instead of varchar(1)?
Even if it was assigned a text datatype it would be the unconstrainted text
not varchar(1). If we used varchar(1) then things like:
create table foo as select
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
I don't have much insight into the operator classes and operator families
and how they work. Where should I look for the related code ?
Primary opclass members are stored right in the Relation data struct for
you. Since (I trust)
For some Unicode character sets, element_width can be as much as 4
In UTF8 one char can be up to 6 bytes, so 4 is not correct in general.
Andreas
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
Here's results from a batch of test runs with LDC. This patch only
spreads out the writes, fsyncs work as before. This patch also includes
the optimization that we don't write buffers that were dirtied after
starting the checkpoint.
http://community.enterprisedb.com/ldc/
See tests 276-280.
* Dave Page ([EMAIL PROTECTED]) wrote:
/* We only show the rel name, not schema name */
relname = get_rel_name(rte-relid);
Anyone know why? This seems like a bug to me given the ambiguity of
possible output.
I'd assume it's to keep the explain output smaller with the
expectation/assumption
Stephen Frost wrote:
* Dave Page ([EMAIL PROTECTED]) wrote:
/* We only show the rel name, not schema name */
relname = get_rel_name(rte-relid);
Anyone know why? This seems like a bug to me given the ambiguity of
possible output.
I'd assume it's to keep the explain output smaller with the
* Dave Page ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
In terms of behaviour changes, I think it'd be nice to show the schema
name when necessary but otherwise don't, ala how '\d view' works.
In my case that would be awkward as pgAdmin would then need to try to
work out what the
Stephen Frost wrote:
Indeed, if you're not constructing the queries that would make things
somewhat difficult. Then again, parsing the explain output seems like
it's going to be rather difficult itself anyway.
Well, we do that anyway - and just grabbing the base table names isn't
too hard.
Stephen Frost wrote:
* Dave Page ([EMAIL PROTECTED]) wrote:
/* We only show the rel name, not schema name */
relname = get_rel_name(rte-relid);
Anyone know why? This seems like a bug to me given the ambiguity of
possible output.
I'd assume it's to keep the explain output smaller with the
On Wed, Jun 13, 2007 at 01:20:25PM +0100, Dave Page wrote:
Just adding the schema name seems the most sensible and usable option -
not to mention the easiest!
While completely ignoring the current behaviour and likely the reason
it's done the way it is now... explain output was, and still
Magnus Hagander wrote:
Just to open a whole new can of worms ;-)
I read an article a couple of days ago about the machine readable showplan
output in SQL Server 2005 (basically, it's EXPLAIN output but in XML
format). It does make a lot of sense if yourp rimary interface is !=
commandline
On Wed, Jun 13, 2007 at 08:47:30AM -0400, Alvaro Herrera wrote:
Magnus Hagander wrote:
Just to open a whole new can of worms ;-)
I read an article a couple of days ago about the machine readable showplan
output in SQL Server 2005 (basically, it's EXPLAIN output but in XML
format). It
Something worth doing? Not to replace the current explain output, but as a
second option (EXPLAIN XML whatever)?
//Magnus
It's good idea. Similar situation is in stack trace output.
Pavel
---(end of broadcast)---
TIP 4: Have you searched our
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 01:20:25PM +0100, Dave Page wrote:
Just adding the schema name seems the most sensible and usable option -
not to mention the easiest!
While completely ignoring the current behaviour and likely the reason
it's done the way it is now... explain
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote:
Something worth doing? Not to replace the current explain output, but as a
second option (EXPLAIN XML whatever)?
I agree it would be nice to have machine readable explain output.
Seconded here, I'd much rather see this as a seperate option
On Wed, Jun 13, 2007 at 02:02:24PM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 01:20:25PM +0100, Dave Page wrote:
Just adding the schema name seems the most sensible and usable option -
not to mention the easiest!
While completely ignoring the current
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 02:02:24PM +0100, Heikki Linnakangas wrote:
DB2 has the concept of explain tables. Explain output is written to
tables, which tools query and pretty print the output. I like that idea
in principle. PostgreSQL is a relational database, so having
Heikki Linnakangas [EMAIL PROTECTED] writes:
How about just doing a memcmp? That would be safe, simple and fast and
covers all interesting use cases.
You'd have to use datumIsEqual() or equivalent, and figure out what to
do about nulls. I think it'd work though, at least for the purposes
that
ITAGAKI Takahiro wrote:
If we tries to drop the table on which autovacuum is running, we have to
wait finish of the vacuum. However, the vacuuming effort goes to waste for
the table being dropped or rewritten. Meanwhile, we've already had the
autovacuum killer triggered in CREATE/DROP/RENAME
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
If we tries to drop the table on which autovacuum is running, we have to
wait finish of the vacuum. However, the vacuuming effort goes to waste for
the table being dropped or rewritten. Meanwhile, we've already had the
autovacuum killer triggered in
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 08:47:30AM -0400, Alvaro Herrera wrote:
Magnus Hagander wrote:
Just to open a whole new can of worms ;-)
I read an article a couple of days ago about the machine readable
showplan
output in SQL Server 2005 (basically, it's
* Alvaro Herrera [EMAIL PROTECTED] [070613 09:58]:
BTW can I bug you to add the Message-Ids in the messages as displayed in
our archives?
Yes! Yes! Yes! Pretty please!
--
Aidan Van Dyk Create like a god,
[EMAIL PROTECTED]
Hi,
I remember there used to be somewhere a link to a talk Tom gave (on
OSCON 2001 maybe?) on transaction processing, SERIALIZABLE, SELECT FOR
UPDATE, etc. I'm pretty sure it was linked to somewhere in the old
developers page, but I cannot find it in the new one or elsewhere. I
searched the
Dave Page [EMAIL PROTECTED] writes:
Looking to fix this, a comment in src/backend/commands/explain.c
indicates that this is intentional:
Quite.
Anyone know why?
As already noted, it'd usually be clutter in lines that are too long
already. Also, conditionally adding a schema name isn't very
On Wed, Jun 13, 2007 at 09:55:19AM -0400, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 08:47:30AM -0400, Alvaro Herrera wrote:
Magnus Hagander wrote:
Just to open a whole new can of worms ;-)
I read an article a couple of days ago about the machine
On 6/13/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 02:02:24PM +0100, Heikki Linnakangas wrote:
DB2 has the concept of explain tables. Explain output is written to
tables, which tools query and pretty print the output. I like that idea
in
Alvaro Herrera [EMAIL PROTECTED] writes:
I remember there used to be somewhere a link to a talk Tom gave (on
OSCON 2001 maybe?) on transaction processing, SERIALIZABLE, SELECT FOR
UPDATE, etc. I'm pretty sure it was linked to somewhere in the old
developers page, but I cannot find it in the
* Zeugswetter Andreas ADI SD ([EMAIL PROTECTED]) wrote:
Wouldn't it be far more logical to decide that if a user has the
permissions to do a DELETE FROM table; then they have permission to
do
a TRUNCATE? Why make an additional permission?
Truncate doesn't fire ON DELETE triggers.
Heikki Linnakangas [EMAIL PROTECTED] writes:
The response time graphs show that the patch reduces the max (new-order)
response times during checkpoints from ~40-60 s to ~15-20 s.
I think that's the headline number here. The worst-case response time is
reduced from about 60s to about 17s.
Magnus Hagander wrote:
Something worth doing? Not to replace the current explain output, but as a
second option (EXPLAIN XML whatever)?
Yeah, thats been mentioned before. I was looking to bring it up for 8.4.
/D
---(end of broadcast)---
TIP 1:
Josh Tolley [EMAIL PROTECTED] writes:
On a different sideline based on the original note of this thread,
much as EXPLAIN doesn't include the schema, \d doesn't include the
schema to describe INHERIT relationships in 8.2.4. If you have two
tables called PARENT, in two different schemas, and a
Nicholas Barr [EMAIL PROTECTED] writes:
At the moment it seems as if a single 32 bit integer is used for the
permissions, with the top half being the grantable rights. I assume I
would need to extend this into two 32 bit integers, or one 64 bit integer?
Two 32-bit please. We are still trying
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I remember there used to be somewhere a link to a talk Tom gave (on
OSCON 2001 maybe?) on transaction processing, SERIALIZABLE, SELECT FOR
UPDATE, etc. I'm pretty sure it was linked to somewhere in the old
developers page, but I
Magnus Hagander [EMAIL PROTECTED] writes:
Assuming you can actually *represent* the whole plan as tables, that would
of course work fine. But I assume you mean virtual tables?
Are you saying there are data structures relational databases aren't good at
representing?
In Oracle you had to run
Tom Lane wrote:
As already noted, it'd usually be clutter in lines that are too long
already. Also, conditionally adding a schema name isn't very good
because it makes life even more complicated for programs that are
parsing EXPLAIN output (yes, there are some).
Well, yes - that's precisely
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries already. XML also could
* Tom Lane ([EMAIL PROTECTED]) wrote:
Nicholas Barr [EMAIL PROTECTED] writes:
At the moment it seems as if a single 32 bit integer is used for the
permissions, with the top half being the grantable rights. I assume I
would need to extend this into two 32 bit integers, or one 64 bit integer?
Alvaro Herrera [EMAIL PROTECTED] writes:
Since this was publically released in the past, I assume this is OK to
distribute?
Sure, no problem.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries already. XML also could
BTW can I bug you to add the Message-Ids in the messages as displayed in
our archives?
That said, you can get the message-id if you do a view-source. It's in a
comment at the beginning of the page.
I hadn't seen that before...
2 bookmarklets I find useful and have in my Personal Toolbar
Andrew Dunstan wrote:
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Looking to fix this, a comment in src/backend/commands/explain.c
indicates that this is intentional:
Quite.
Anyone know why?
As already noted, it'd usually be clutter in lines that are too long
already. Also, conditionally adding a
Tom Lane [EMAIL PROTECTED] writes:
Dave Page [EMAIL PROTECTED] writes:
Looking to fix this, a comment in src/backend/commands/explain.c
indicates that this is intentional:
Quite.
Anyone know why?
As already noted, it'd usually be clutter in lines that are too long
already. Also,
Joshua D. Drake [EMAIL PROTECTED] writes:
I agree. XML seems like a fairly natural fit for this. Just as people should
not try to shoehorn everything into XML, neither should they try to shoehorn
everything into a relational format either.
Now all we need is an XML schema for it ;-)
Well I
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
And you stick them in a well-defined XML format (or another
format if you happen to hate XML) where the client-side program can easily
parse out whatever it needs. It's also future-proof - if you add a new
field somewhere, the client
On 6/13/07, Tom Lane [EMAIL PROTECTED] wrote:
Josh Tolley [EMAIL PROTECTED] writes:
On a different sideline based on the original note of this thread,
much as EXPLAIN doesn't include the schema, \d doesn't include the
schema to describe INHERIT relationships in 8.2.4. If you have two
tables
On Wed, 13 Jun 2007, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I remember there used to be somewhere a link to a talk Tom gave (on
OSCON 2001 maybe?) on transaction processing, SERIALIZABLE, SELECT FOR
UPDATE, etc. I'm pretty sure it was linked to somewhere in the old
ITAGAKI Takahiro wrote:
Alvaro Herrera [EMAIL PROTECTED] wrote:
No, I meant a while (sleep 1(or 10) and counter longtime) check for
exit instead of sleep longtime.
Ah; yes, what I was proposing (or thought about proposing, not sure if I
posted it or not) was putting a upper
I've been looking at the tsearch patch a bit, and I think there needs to
be more thought given to the permissions required to mess around with
tsearch configuration objects.
The TSParser objects reference functions declared to take and return
INTERNAL arguments. This means that the underlying
Josh Tolley [EMAIL PROTECTED] writes:
On 6/13/07, Tom Lane [EMAIL PROTECTED] wrote:
Yes it does, because that's actually regclass output. It'll be
schema-qualified if the table is not visible in your search path.
I figured it was better to start a new thread, since this changes from
the
Gregory Stark [EMAIL PROTECTED] writes:
Arguably this is a bug if it's causing pg_admin difficulties in parsing the
output. Even for a user in an environment where, for example, he has several
identical schemas and may be accidentally getting a different table than he's
expecting the current
On Sun, Jun 10, 2007 at 08:49:24PM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Thinking about this whole idea a bit more, it occured to me that the
current approach to write all,
Greg,
However TPC-E has even more stringent requirements:
I'll see if I can get our TPCE people to test this, but I'd say that the
existing patch is already good enough to be worth accepting based on the TPCC
results.
However, I would like to see some community testing on oddball workloads
Alvaro Herrera wrote:
Ah; yes, what I was proposing (or thought about proposing, not sure if I
posted it or not) was putting a upper limit of 10 seconds in the sleep
(bgwriter sleeps 10 seconds if configured to not do anything). Though
10 seconds may seem like an eternity for systems
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I agree. XML seems like a fairly natural fit for this. Just as people should
not try to shoehorn everything into XML, neither should they try to shoehorn
everything into a relational format either.
Now all we need is an XML schema
$subject would be bad because of potential deadlocks against other
transactions that might try to exclusive-lock more than one table.
We should be OK for actual vacuum operations, but I think that if
autovac chooses to just ANALYZE multiple tables, it will do it in
one transaction and accumulate
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I agree. XML seems like a fairly natural fit for this. Just as people should
not try to shoehorn everything into XML, neither should they try to shoehorn
everything into a relational format either.
Now all we need is an XML schema
Heikki Linnakangas wrote:
Jim C. Nasby wrote:
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Thinking about this whole idea a bit more, it occured to me that the
current approach to write all, then fsync all is really a historical
You bring up a very good point. There are fifteen new commands being
added for full text indexing:
alter-fulltext-config.sgml alter-fulltext-owner.sgml
create-fulltext-dict.sgml drop-fulltext-dict.sgml
alter-fulltext-dict.sgmlalter-fulltext-parser.sgml
Gregory Stark [EMAIL PROTECTED] writes:
Once you have an XML plan what can you do with it? All you can do is parse it
into constituent bits and display it. You cant do any sort of comparison
between plans, aggregate results, search for plans matching constraints, etc.
Sure you can, just not in
If we extended relations by more than 8k at a time, we would know a lot
more about disk layout, at least on filesystems with a decent amount of
free space.
I doubt it makes that much difference. If there was a significant amount
of fragmentation, we'd hear more complaints about seq scan
What is the state of play with this item? I think this is a must-fix bug
for 8.3. There was a flurry of messages back in April but since then I
don't recall seeing anything.
cheers
andrew
Mark Dilger wrote:
Mark Dilger wrote:
Bruce Momjian wrote:
Added to TODO:
* Fix cases where
Tom Lane wrote:
$subject would be bad because of potential deadlocks against other
transactions that might try to exclusive-lock more than one table.
We should be OK for actual vacuum operations, but I think that if
autovac chooses to just ANALYZE multiple tables, it will do it in
one
How about adding to the general TODO in case someone finds time
before Simon?
On Jun 10, 2007, at 5:55 PM, Simon Riggs wrote:
On Sun, 2007-06-10 at 20:48 +0200, [EMAIL PROTECTED] wrote:
My questions was: why don't we start the archiving *BEFORE*
postmaster to
make room.
The archiver is
Alvaro Herrera [EMAIL PROTECTED] writes:
Sure, it can do that. I think it's easy enough to correct this problem;
see attached patch. Should this be backpatched? Earlier releases also
fall foul of this problem AFAICT.
Yeah, because what made me think about it was a gripe from an 8.2
user ...
On 6/13/07, Gregory Stark [EMAIL PROTECTED] wrote:
I'm not a fan either so perhaps I'm biased, but this seems like a good example
of where it would be an *awful* idea.
Once you have an XML plan what can you do with it? All you can do is parse it
into constituent bits and display it.
...and
70 matches
Mail list logo
