On Thursday 15 December 2005 00:52, you wrote:
> On Wed, 2005-12-14 at 17:47 -0500, Tom Lane wrote:
> > That plan looks perfectly fine to me. You could try forcing some other
> > choices by fooling with the planner enable switches (eg set
> > enable_seqscan = off) but I doubt you'll find much impr
On Wednesday 14 December 2005 18:36, you wrote:
> Well - that had no effect at all :-) You don't have and index on
> to_ship.ordered_product_id do you? - try adding one (ANALYZE again), and
> let use know what happens (you may want to play with SET
> enable_seqscan=off as well).
I _DO_ have an ind
"Gregory S. Williamson" <[EMAIL PROTECTED]> writes:
> Forgive the cross-posting, but I found myself wondering if might not
> be some way future way of telling the planner that a given table
> (column ?) has a high likelyhood of being TOASTed.
What would you expect the planner to do with the inform
On Thu, 15 Dec 2005, Harry Jackson wrote:
> Hi all,
> I have been using PostgreSQL (currently 7.4.7) for several years now and
> am very happy with it but I currently run a website that has had a
> little bit of a boost and I am starting to see some performance problems
> (Not necessarily Postgre
I have been using PostgreSQL (currently 7.4.7) for several years now and
am very happy with it but I currently run a website that has had a
little bit of a boost and I am starting to see some performance problems
(Not necessarily PostgreSQL).
PostgreSQL 8.1.1 should give you greater performanc
Hi all,
I have been using PostgreSQL (currently 7.4.7) for several years now
and am very happy with it but I currently run a website that has had a
little bit of a boost and I am starting to see some performance
problems (Not necessarily PostgreSQL).
The original website server ran on a singl
Kevin Brown wrote:
I only had two explicit indexes. One was on to_ship.ordered_product_id and
the other was on ordered_products.paid. ordered_products.id is a primary
key. This is on your query with an index added on suspended_sub:
dli=# explain analyze SELECT ordered_products.product_i
Forgive the cross-posting, but I found myself wondering if might not be some
way future way of telling the planner that a given table (column ?) has a high
likelyhood of being TOASTed. Similar to the random_page_cost in spirit. We've
got a lot of indexed data that is spatial and have some table
On Wednesday 14 December 2005 17:30, Mark Kirkwood wrote:
> You scan 60 rows from to_ship to get about 25000 - so some way to
> cut this down would help.
Yup. I'm open to anything too, as this is the only real part of the system
that cares. So either maintaining a denormalized copy column,
On Wednesday 14 December 2005 17:23, you wrote:
> what hardware?
Via 800 mhz (about equiv to a 300 mhz pentium 2)
128 mb of slow ram
4200 rpm ide hard drive.
Told you it was slow. :-)
This is not the production system. I don't expect this to be "fast" but
everything else happens in under 2 sec
On Wed, Dec 14, 2005 at 04:03:52PM -0600, Kevin Brown wrote:
> -> Index Scan using paid_index on ordered_products
> (cost=0.00..4954.79 rows=21759 width=16) (actual time=136.472..5966.275
> rows=18042 loops=1)
>Index Cond: (paid = true)
>Filter: (paid AN
Kevin Brown wrote:
I'll just start by warning that I'm new-ish to postgresql.
I'm running 8.1 installed from source on a Debian Sarge server. I have a
simple query that I believe I've placed the indexes correctly for, and I
still end up with a seq scan. It makes sense, kinda, but it should b
On 12/14/05, Kevin Brown <[EMAIL PROTECTED]> wrote:
> I'll just start by warning that I'm new-ish to postgresql.
>
> I'm running 8.1 installed from source on a Debian Sarge server. I have a
> simple query that I believe I've placed the indexes correctly for, and I
> still end up with a seq scan.
On Wednesday 14 December 2005 16:47, you wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I'm running 8.1 installed from source on a Debian Sarge server. I have a
> > simple query that I believe I've placed the indexes correctly for, and I
> > still end up with a seq scan. It makes sense, kin
Kevin Brown <[EMAIL PROTECTED]> writes:
> I'm running 8.1 installed from source on a Debian Sarge server. I have a
> simple query that I believe I've placed the indexes correctly for, and I
> still end up with a seq scan. It makes sense, kinda, but it should be able
> to use the index to gathe
Thanks, now the SELECT from the huge VIEW runs under one third of the
original runtime.
Nice.
select * from v1 where code||num = 'AAA200501';
I do not know if it is at all possible, but maybe you could use a rule
to, on select to your view, do instead a select on the two sepa
I'll just start by warning that I'm new-ish to postgresql.
I'm running 8.1 installed from source on a Debian Sarge server. I have a
simple query that I believe I've placed the indexes correctly for, and I
still end up with a seq scan. It makes sense, kinda, but it should be able
to use the in
PFC írta:
create view v1 (code,num) as
select 'AAA',id from table1
union
select 'BBB',id from table2;
As your rows are, by definition, distinct between each subquery,
you should use UNION ALL instead of UNION to save postgres the
trouble of hunting non-existing duplicates. This will
create view v1 (code,num) as
select 'AAA',id from table1
union
select 'BBB',id from table2;
As your rows are, by definition, distinct between each subquery, you
should use UNION ALL instead of UNION to save postgres the trouble of
hunting non-existing duplicates. This will save you a few
Hi,
we have a VIEW that is an UNION of 12 SELECTs, and every
member of the UNION have a constant field to be able to distinguish
between them.
An often performed operation on this VIEW is to search for only one record
that can be found by the value of the constant field and the serial of
a table
On Wed, Dec 14, 2005 at 11:53:52AM -0500, Andrew Rawnsley wrote:
Other goofy things about it: it isn't 1 device with 14 disks and redundant
controllers. Its 2 7 disk arrays with non-redundant controllers. It doesn't
do RAID10.
And if you want hot spares you need *two* per tray (one for each
con
The Apple is, as you say, cheap (except, the Apple markup on the disks
fuzzes that a bit). Its easy to set up, and has been quite reliable for me,
but do not expect anything resembling good DB performance out of it (I gave
up running anything but backup DBs on it). From the mouth of Apple guys, it
<[EMAIL PROTECTED]> writes:
> /*
>* The sub-select must not refer to any Vars of the parent query.
>* (Vars of higher levels should be okay, though.)
>*/
> if (contain_vars_of_level((Node *) subselect, 1))
> return NULL;
> By commenting this code
Title: Dear Sir or Madam:
Dear Sir or Madam:
The function "convert_IN_to_join(Query *parse, SubLink *sublink)",
from file: /src/backend/optimizer/plan/subselect.c,
is responsible for converting IN type sublinks to joins, whenever
appropriate.
The following lines of code, extracted from co
24 matches
Mail list logo
