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 fro
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 sur
"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
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) yo
> 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. 28
* 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/assump
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
exp
* 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 ' works.
>
> In my case that would be awkward as pgAdmin would then need to try to
> work out what the ac
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
exp
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,
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 !=
> comma
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
>
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 l
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 out
* 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
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 t
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
t
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/RENAM
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
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 (
* 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 OSCO
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 v
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
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 ide
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
> * 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
"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,
"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 t
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
"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
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 wh
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 bi
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
d
> > 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
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 al
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 sch
"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
> alr
"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
-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 pro
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
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
develope
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
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 fun
"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 fr
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 curr
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
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 syst
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 sch
$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 l
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 sche
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
arti
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 no
>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 perfor
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 i
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
68 matches
Mail list logo
