On Mon, 19 Feb 2001, Joseph Shraibman wrote:
> > Of course, if the 10113-match estimate is wildly off (as it was in this
> > case), then the wrong plan may be chosen. But it IS NOT CORRECT to
> > suppose that indexscans always beat seqscans. The planner's job would
> > be a lot easier if that
Joseph Shraibman wrote:
>
> Can't postgres do the index lookup first and find out there are only a
> few tuples that might match?
>
Actually it looks like postgres is doing this:
o=# explain select * from usertable where p = 33;
NOTICE: QUERY PLAN:
Seq Scan on usertable (cost=0.00..30.54 r
Tom Lane wrote:
>
> Joseph Shraibman <[EMAIL PROTECTED]> writes:
> > Stephan Szabo wrote:
> >> Do you have a value that is not null that is very common?
> >> It's estimating that there will be 10113 rows that match
> >> nomsession='xxx' which makes a seq scan a much less bad plan.
> >>
> > Err, w
Joseph Shraibman <[EMAIL PROTECTED]> writes:
> Stephan Szabo wrote:
>> Do you have a value that is not null that is very common?
>> It's estimating that there will be 10113 rows that match
>> nomsession='xxx' which makes a seq scan a much less bad plan.
>>
> Err, why? There is an index, isn't th
On Mon, 19 Feb 2001, Joseph Shraibman wrote:
> Stephan Szabo wrote:
> >
> > Do you have a value that is not null that is very common?
> > It's estimating that there will be 10113 rows that match
> > nomsession='xxx' which makes a seq scan a much less bad plan.
> >
> Err, why? There is an inde
> At 10:09 AM 19-02-2001 -0500, Bruce Momjian wrote:
> >
> >We still need to reset any 'SET' commands used, but that can't be done
> >for 7.1.
>
> Would you have to do an unlisten *?
>
> Are there other per connection things as well?
Wow, yes, there are probably many things we will need to do t
Stephan Szabo wrote:
>
> Do you have a value that is not null that is very common?
> It's estimating that there will be 10113 rows that match
> nomsession='xxx' which makes a seq scan a much less bad plan.
>
Err, why? There is an index, isn't there? Shouldn't the index allow
postgres to quickl
At 10:09 AM 19-02-2001 -0500, Bruce Momjian wrote:
>
>We still need to reset any 'SET' commands used, but that can't be done
>for 7.1.
Would you have to do an unlisten *?
Are there other per connection things as well?
Cheerio,
Link.
In 7.0 it is rather obvious. In 7.1 they moved to a number based
scheme. I suggested they make a symlink with the name of the table
pointing at the numbered file, but I don't think anyone paid attention.
The info is in one of the pg_ tables, I don't know which one
offhand.
Louis-David Mitt
Was there something wrong with dbf2sql? :-) It used to be in contribs/ I
think but it was very simple code that did the job. At the time I was
working with 1.x and 6.0x versions of Postgres and made a few mods to it so
that I could rename the tables, change field types, just export the data and
A friend asked me to figure out how to access PostgreSQL from Tcl via
ODBC. For posterity, here's the step by step "how I did it" that I
emailed to him. I don't know Tcl, this was just about getting the
compile options correct and doing the proper sysadminning to make
things work.
Comments, sugge
I have a table/class filled with records/instances in which I accidentally
set the fields/attributes data type to text rather than boolean. I now have
75,000 records with 't' and 'f' So now I want to change the attributes to
bool? I can't find anything on changing data types in the integrated docs
I've noticed that select max(the_primary_key) from some_table
does a table scan. Is there any plan to implement max/min calculations
using index lookups if the appropriate index exists?
Thanks,
Alex.
On Mon, 19 Feb 2001, Mark Cowlishaw wrote:
>
> I noticed that running queries that do -not- use declared table aliases in
> the 'where' clause seem to run a hell-of-a-lot slower than when aliases are
> used. Is there a valid reason for this? It started out as a typo but now I'm
> curious.
Well
You can reconstruct the information out of the triggers
that are created in pg_trigger. It's not easy to
parse however.
There are three triggers created for each fk constraint,
one on the fk table, two on the pk table. You can
get the tables, columns constrained and match type from
the tgargs
> > yes. I ran VACUUM ANALYZE after creating the indicies. (Actually, I VACUUM
> > the database twice a day.) The data table literally has 145972 rows, and
> > 145971 will match conf_id 4...
>
> Hm. In that case the seqscan on data looks pretty reasonable ... not
> sure if you can improve on thi
Dave Edmondson <[EMAIL PROTECTED]> writes:
> yes. I ran VACUUM ANALYZE after creating the indicies. (Actually, I VACUUM
> the database twice a day.) The data table literally has 145972 rows, and
> 145971 will match conf_id 4...
Hm. In that case the seqscan on data looks pretty reasonable ... not
On Mon, Feb 19, 2001 at 12:22:11PM -0500, Tom Lane wrote:
> Dave Edmondson <[EMAIL PROTECTED]> writes:
> > Ack! I just timed it at 74 seconds.
> > Added two indexes, here's the query plan... it doesn't seem to be using the
> > indexes at all. I'm sure I'm doing something wrong here...
>
> Have yo
Dave Edmondson writes:
> Added two indexes, here's the query plan... it doesn't seem to be using the
> indexes at all. I'm sure I'm doing something wrong here...
>
> NOTICE: QUERY PLAN:
>
> Sort (cost=6707.62..6707.62 rows=10596 width=170)
> -> Merge Join (cost=1.34..5492.29 rows=10596 widt
Simon Attwell <[EMAIL PROTECTED]> writes:
> How does postgresql deal with locking when one has a large select
> query running on a > 700,000 row table, when there are inserts pending
> for that table.
> I have an application that does a _lot_ of inserts, and a frontend that
> makes large long lab
Simon Attwell writes:
> How does postgresql deal with locking when one has a large select query running
> on a > 700,000 row table, when there are inserts pending for that table.
The insert and select can happen in parallel. See
http://www.postgresql.org/users-lounge/docs/7.0/postgres/mvcc.htm
The below is what I'd like:
select * from table natural join (select tablename from table where
table_id = 'rid');
select tablename from table where table_id = 'rid'; returns 'table2'
So, the equivalent of what I'd like in this case is: select * from
table natural join table2;
I could do th
Ack! I just timed it at 74 seconds.
Added two indexes, here's the query plan... it doesn't seem to be using the
indexes at all. I'm sure I'm doing something wrong here...
NOTICE: QUERY PLAN:
Sort (cost=6707.62..6707.62 rows=10596 width=170)
-> Merge Join (cost=1.34..5492.29 rows=10596 wid
Just an FYI.
> FWIW, I emailed the php maintainer of the postgres piece, and he replied
> with the following (I installed the patch, recompiled, and everything has
> been running fine for about a week or so)
>
> Michael Fork - CCNA - MCP - A+
> Network Support - Toledo Internet Access - Tole
How does postgresql deal with locking when one has a large select query running
on a > 700,000 row table, when there are inserts pending for that table.
I have an application that does a _lot_ of inserts, and a frontend that
makes large long laborious select queries on the same tables.
MySQL has
> should PHP4's persistent connection be used at all? i was going back to
> the mailing list archive and there were discussions about the use of
> persistent connections and interference of one script with another
> in between begin/commits. any clarifications?
>
> was that issue with PHP not reu
26 matches
Mail list logo
