> EXPLAIN
> tour=# explain analyze select * from tours where
>( operator_id in (2,3,4,5,7) and type_id = 4 ) or
>( operator_id = 8 and type_id = 3);
> NOTICE: QUERY PLAN:
>
> Index Scan using type_idx, type_idx, type_idx, type_idx, type_idx, type_idx on tours
> (cost=
Le Mardi 14 Mai 2002 03:29, Tatsuo Ishii a écrit :
> For example, user
> might want to have a table like this in a UTF-8 database:
>
> create table t1(
>english text,-- English message
>germany text,-- Germany message
>japanese text-- Japanese message
> );
Or j
On Tue, 2002-05-14 at 07:08, Tom Lane wrote:
> You have no fear that that "sed" will substitute some places it
> shouldn't have? Also, what makes you think this'll be a "rarely
> used" feature? I'd guess that people load dumps every day into
> databases that have different names than the ones th
Oliver Elphick <[EMAIL PROTECTED]> writes:
>> Perhaps instead of "readability" I should have said "editability".
>> The thought that is lurking behind this is that you might want to
>> retarget a dump script to be reloaded in some other schema. If the
>> dump is cluttered with umpteen thousand co
On Tue, 2002-05-14 at 01:42, Tom Lane wrote:
> [EMAIL PROTECTED] (Neil Conway) writes:
> > I'd prefer this method -- IMHO the readibility of dump scripts isn't
> > a top priority (or if it is, we're not doing very well in that regard
> > any). I think dump scripts should be as verbose as is necess
> Actually, even for those that wuldn't need the patch ... as long as the
> "default behaviour" doesn't change, and unless there are no valid
> technical arguments around it, there is no reason why a patch shouldn't be
> included ...
Unless it's going to interfere with implementing the general ca
On Mon, 13 May 2002, Lamar Owen wrote:
> But understand that those who don't need the functionality are likely not not
> be thrilled by changes to a currently stable codebase. Although this config
> file stuff is small potatoes compared to the Win32 stuff as recently
> discussed. And for that,
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> # create view aview as select ctid, * from a_table;
> ERROR: name of column "ctid" conflicts with an existing system column
> If there's no objection I would remove system columns
> from views and allow the second example.
I seem to recall having loo
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> How did you intend on dealing with the case where a user removes
> public or otherwise changes the permissions / ownership on it?
I have that as one of my "to think about" items. The best idea I have
at the moment is to assume it exists, but include GRA
Lamar Owen <[EMAIL PROTECTED]> writes:
> Although this config file stuff is small potatoes compared to the
> Win32 stuff as recently discussed. And for that, please understand
> that most of the developers here consider Win32 an inferior server
> platform. In fact, Win32 _is_ an inferior server
> Doesn't seem very workable for the public schema. I suspect pg_dump
> has to special-case public anyway, to some extent, but this doesn't
> really get us around the DROP problem for individual objects AFAICS.
Most people in the know will probably never use public due to
portability issues betw
> I think it is really not hard to do this for UTF-8. I don't have to know the
> relation between the locale and the encoding. Look at this:
> We can use the LC_CTYPE from pg_controldata or alternatively the LC_CTYPE
> at server startup. For nearly every locale (de_DE, ja_JP, ...) there exists
> a
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> ... Based on the assumption a DROP SCHEMA statement will also
> be issued.
Doesn't seem very workable for the public schema. I suspect pg_dump
has to special-case public anyway, to some extent, but this doesn't
really get us around the DROP problem for
> No, it's a necessary thing to comply with the SQL standard.
> The standard thinks all the predefined names are keywords and
> should override user names. Therefore there *must* be a mode
Hmm.. I'm not fond of this part of the standard in this case -- though
it's got to be there for good reaso
[EMAIL PROTECTED] (Neil Conway) writes:
> I'd prefer this method -- IMHO the readibility of dump scripts isn't
> a top priority (or if it is, we're not doing very well in that regard
> any). I think dump scripts should be as verbose as is necessary to
> ensure that they can't be misinterpreted.
P
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Afterall, if you create a my_schema.pg_class table (for whatever
> reason), and used my search path as my_schema, I'd expect my own to be
> hit with my queries.
If you want that behavior, you can set the search path as
"my_schema, pg_catalog". This does
On Mon, May 13, 2002 at 02:58:08PM -0400, Tom Lane wrote:
> 1. Explicitly qualify target-object names in the DROP commands,
> 2. Modify the backend so that DROP has a different behavior from
> other commands
> Choice #1 is logically cleaner but would clutter the dump script with
> many more expl
Hi all,
I see the following for a view a_view;
# select ctid, xmin, cmin, xmax, cmax, tableoid from a_view;
ctid | xmin | cmin | xmax | cmax | tableoid
--+--+--+--+--+--
| | | | |
| | | | |
| | |
> A limited-to-that-table dump/fix/restore can be a problem because of
the
> interrelationships of RI among tables. If there were any easier way
to dump
> information about a table so that I could restore the RI that other
tables
> have on it, that might be a solution.
Agreed about making that ea
> set search_path = my_schema;
> This works fine unless the object name duplicates a system object;
> in that case, since the effective search path is really "pg_catalog,
> my_schema", the DROP will find and try to drop the system object.
I must have missed that day. Why is that exactly? Clien
[trimmed cc list, but left on HACKERS due to the nature of the subject (which
was changed]
On Monday 13 May 2002 10:56 am, mlw wrote:
> Iavor Raytchev wrote:
> > Peter Eisentraut wrote:
> > > let's see some code.
> > I do not feel neither like 'asking for permisson', nor like 'proving'
> > anyth
In current sources (compiled without --enable-integer-datetimes) I get
regression=# select interval(0) '1 day 23:44:55.667677' ;
interval
---
1 day 23:44:55.667677
(1 row)
I was expecting it to round off ... I think there's something wrong with
the arithmetic in Adju
On Mon, 13 May 2002, mlw wrote:
> Iavor Raytchev wrote:
> >
> > > If and when patches for pgaccess appear in significant numbers and for
> > > some reason, which I cannot imagine, this procedure doesn't end up being
> > > practical, we can consider the alternatives. But before you spend a lot
>
> I still highly recommend that it be a drop foreign key, grab data,
> truncate, import data, reapply foreign key (which will double check
> your work) as I believe data and schema integrity should be high goals
> of Postgresql (myself anyway).
I agree that they should be high goals.
> However,
I'm working on cleaning up loose ends in pg_dump, and in particular
trying to ensure that objects in user schemas can be named the same
as system objects without conflicts. Most of this works now, thanks
to Peter's idea about explicitly setting the search path to include
just the current target s
Tom,
one more question.
What's the difference for planner between 2 queries ?
For the first query I have plain index scan, but multiple
index scan for second.
tour=# explain analyze select * from tours where
( operator_id in (2,3,4,5,7) and type_id = 2 );
NOTICE: QUERY PLAN:
I
Thanks Tom,
On Mon, 13 May 2002, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > tour=# explain analyze select * from tours where
> > ( operator_id in (2,3,4,5,7) and type_id = 2 ) or
> > ( operator_id = 8 and type_id=4 );
>
> > Index Scan using type
Iavor Raytchev wrote:
>
> > If and when patches for pgaccess appear in significant numbers and for
> > some reason, which I cannot imagine, this procedure doesn't end up being
> > practical, we can consider the alternatives. But before you spend a lot
> > of time building a new infrastructure, l
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> What's the difference for planner between 2 queries ?
> tour=# explain analyze select * from tours where
> ( operator_id in (2,3,4,5,7) and type_id = 2 );
> tour=# explain analyze select * from tours where
>( operator_id i
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Is this what the TODO entry 'Make IN / NOT IN have similar performance
> as EXISTS' means?
No. The TODO item is talking about IN with a sub-SELECT, which is not
optimized at all at the moment. IN with a list of scalar values is
converted to ((x = value
On Fri, 10 May 2002, large scale wrote:
> Hi,
>
> I have two tables, one has 25000 rows and the other
> has 6.5 million rows.
>
> (25000 rows)
> table1
> (id text,
> start int,
> stop int)
>
> with seperate index on three individual fiels.
>
> 6.5 million rows
> table2
> (id text,
> start
It appears it scanes the type_idx once per opereator. IN gets broken
down into ORs
Is this what the TODO entry 'Make IN / NOT IN have similar performance
as EXISTS' means?
--
Rod
- Original Message -
From: "Oleg Bartunov" <[EMAIL PROTECTED]>
To: "Pgsql Hackers" <[EMAIL PROTECTED]>; "Tom
large scale <[EMAIL PROTECTED]> writes:
> Aggregate (cost=353859488.21..353859488.21 rows=1
> width=78)
> -> Merge Join (cost=1714676.02..351297983.38
> rows=1024601931 width=78)
> -> Index Scan using genescript_genomseqid on
> genescript (cost=0.00..750.35 rows=25115 width=62)
>
Of course, something else you may want to do is is allow postgresql to
use a whack load more sort space in ram -- assumming you have ram
free.
Its probably hitting the disk alot for temporary storage space.
http://www.ca.postgresql.org/docs/momjian/hw_performance/
http://www.argudo.org/postgresq
The big problem with the query probably isn't the scans due to your
dataset and the way indexes work.
I'm actually rather surprised it chose an index in the smaller table.
It's the agregate thats taking the time. Which means, faster CPU or
simpler aggregate will do the trick. Ie. Do you really
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> tour=# explain analyze select * from tours where
> ( operator_id in (2,3,4,5,7) and type_id = 2 ) or
> ( operator_id = 8 and type_id=4 );
> Index Scan using type_idx, type_idx, type_idx, type_idx, type_idx, type_idx on tours
mlw,
On Fri, May 10, 2002 at 05:25:02PM -0400, mlw wrote:
> A binary version of PostgreSQL for Windows should not use the cygwin
> dll. I know and understand there is some disagreement with this position,
> but in this I'm sure about this.
Sorry, but I'm not going to touch the above -- even with
Thomas :)))
In Europe it is 1:40 a.m.
Wish you a good night :)
And thanks,
Iavor
--
TNGoEDWAIIAP
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 11, 2002 1:32 AM
To: Iavor Raytchev
Cc: pgsql-hackers; Tom Lane; Stanislav Grozev; Ross J. Reedst
Ross J. Reedstrom writes:
> All very practical, execpt for one point: the people being pulled togther
> for this _have_ code, with nowhere to put it: they've been developing
> new features for pgaccess, on top of the stable pgsql. Tracking CVS
> tip means that the current version of pgaccess ther
Hi,
I've got performance problem and while I'dont ready to describe it
I'd like to ask about strange explain:
tour=# explain analyze select * from tours where
( operator_id in (2,3,4,5,7) and type_id = 2 ) or
( operator_id = 8 and type_id=4 );
NOTICE: QUERY PLAN:
On 2002.05.11 14:15 Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
>
> > All very practical, execpt for one point: the people being pulled
> togther
> > for this _have_ code, with nowhere to put it: they've been
> developing
> > new features for pgaccess, on top of the stable pgsql. Tracking
Hello everybody,
I personally had enough discussions during the last few days. I want to
thank everybody who expressed their opinion and to remind you all that we
started as a small group of four people who actively use and patch pgaccess
now, asked by Teo to see what we can do about bringing our
...
> If nobody feels like managing this - let's give it a little bit of life and
> move it a bit forwards - and then talk again.
Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavo
In the Documentation section of www.pgaccess.org I am trying to build a
small sub-section where I list with few words what people use pgaccess for.
Please, drop a line if you have been using it for something useful.
Please, drop a line if you could not use it for something due to
bugs/missing fe
> Actually, CVS can support this just fine (I'll mention how below) but
> afaict the discussion is moot because Iavor has declared that his group
> prefers to take another path for now.
>
>- Thomas
It is not 'my' group! I just happened to ask somebody in my company to patch
so
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We went through a very similar situation with the JDBC driver a release
> ago. A number of people had developed fixes or features for the driver
> and no one was collecting them. We've got those people working on the 7.2
> branch and everything work
Hello,
Per the suggestion in the README.rmp-dist document with the 7.2.1 rpm I
would like to officially vote for an easy upgrade. I personally think it's
ridiculous that there's no way to go directly from 7.1.3 to 7.2.1.
Oh well :) Other than that and a few other minor issues which don't even
On Sat, 11 May 2002, Tom Lane wrote:
> Au contraire --- what the JDBC folk did (and still are doing) was to
> make "unofficial" releases consisting of snapshots pulled from their
> chunk of the CVS tree. There were people making use of the "7.2 branch"
> of JDBC long before the 7.2 server went b
Tatsuo Ishii wrote:
>
> [Cc:ed to hackers]
>
> (trying select convert(lower(convert('X', 'LATIN1')),'LATIN1','UNICODE');)
>
> > Ok, this is working now (I cann't reproduce why not at the first time).
>
> Good.
>
> > Is it planned to implement it so that I can write lower()/ upper() for multib
Okay, this, and any other thread, concerning pgaccess, should be moved to
-interfaces .. not sure why it was ever on -hackers, actually, but that is
neither here-nor-there ...
On Sat, 11 May 2002, Iavor Raytchev wrote:
> In the Documentation section of www.pgaccess.org I am trying to build a
>
...
> While it would be nice to have one pgaccess that can work with any pgsql
> backend, that's not currently the case. One solution would be to work
> on the release branch, but that's discouraged - bug fixes only.
Actually, CVS can support this just fine (I'll mention how below) but
afaict the
On Fri, May 10, 2002 at 11:24:40PM +0200, Peter Eisentraut wrote:
> Iavor Raytchev writes:
>
> > 3] Still - the only thing that is not clear to me is - who is going to
> > collect all patches and make one whole form them. As long as each of us
> > works on a different thing - this should not be a
Hi,
I have two tables, one has 25000 rows and the other
has 6.5 million rows.
(25000 rows)
table1
(id text,
start int,
stop int)
with seperate index on three individual fiels.
6.5 million rows
table2
(id text,
start int,
stop int)
with seperate index on three individual fields.
When
Iavor Raytchev writes:
> 3] Still - the only thing that is not clear to me is - who is going to
> collect all patches and make one whole form them. As long as each of us
> works on a different thing - this should not be a big problem, but still -
> needs to be one person.
As far as I'm concerned
> If and when patches for pgaccess appear in significant numbers and for
> some reason, which I cannot imagine, this procedure doesn't end up being
> practical, we can consider the alternatives. But before you spend a lot
> of time building a new infrastructure, let's see some code.
>
> --
> Pete
I still highly recommend that it be a drop foreign key, grab data,
truncate, import data, reapply foreign key (which will double check
your work) as I believe data and schema integrity should be high goals
of Postgresql (myself anyway).
However, I'd like to know what your doing. ie. Why is this
Tom Lane wrote:
>
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > Looks like CommentOperator goes to quite a bit of work (5 lines) to
> > accomplish fetching the procedure and states specifically it's not a
> > bug.
>
> Yeah, someone once thought it was a good idea, but I was wondering about
> th
57 matches
Mail list logo
