Brian Connolly writes:
> Any help that you can provide would be greatly appreciated.
I'd suggest trying to get rid of the weird little subselects, like this
one:
> ... SELECT * FROM assayresult."c69d129_particle_size_result_fields"
> WHERE (((SELECT Container FROM exp.Data WHERE RowId = DataId
Hey Brian,
Brian Connolly wrote:
> (I had to send a follow up email due the length of email restrictions on the
> mailing list.)
A tip for when you have this problem in the future -- turn off html mail.
It will reduce your email message length by 50% - 90%.
HTH
Bosco.
--
Sent via pgsql-perfor
Here is the explain analyze output for when enable_material is 'off' and
information on the postgresql version, settings and server configuration (I
had to send a follow up email due the length of email restrictions on the
mailing list.)
(I apologize for the length of these email messages. And if
Tom Lane wrote:
> Actually, in the type of case Mark is showing, the estimates might
> be *more* accurate since the condition gets decomposed into
> separate per-table conditions. I'm still dubious about how often
> it's a win though.
>
> There's another problem, which is that transforming to
Robert Haas writes:
> On Tue, Jan 26, 2010 at 11:41 AM, Tom Lane wrote:
>> I'd suggest going with the UNION. We are unlikely to make the planner
>> look for such cases, because usually such a transformation would be a
>> net loss. It seems like rather a corner case that it's a win even on
>> yo
On Tue, Jan 26, 2010 at 11:41 AM, Tom Lane wrote:
> Mark Hills writes:
>> One of our most-used queries performs poorly (taking over 2 seconds) and a
>> tiny amount of refactoring shows it can be fast (less than 1ms) by
>> transforming the OR case (which spans two tables) into a UNION.
>
> I'd sug
Mark Hills writes:
> One of our most-used queries performs poorly (taking over 2 seconds) and a
> tiny amount of refactoring shows it can be fast (less than 1ms) by
> transforming the OR case (which spans two tables) into a UNION.
I'd suggest going with the UNION. We are unlikely to make the p
just create index on both columns:
CREATE INDEX foo_i ON foo(bar1, bar2);
HTH
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Thu, Jul 9, 2009 at 3:34 PM, Alex wrote:
> Below is a query that takes 16 seconds on the first run. I am having
> generally poor performance for queries in uncached areas of the data
> and often mediocre (500ms-2s+) performance generallly, although
> sometimes it's very fast. All the queries a
Thanks. That's very helpful. I'll take your suggestions and see if
things improve.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
>
> How is the index sl_city_etc defined?
>
Index "public.sl_city_etc"
Column|Type
--+-
city | text
listing_type | text
post_time| timestamp without time zone
bedrooms | integer
region | text
geo_lat |
On Wed, Jul 15, 2009 at 8:51 AM, Alex wrote:
> Also posted this to the list. Thanks for your answer - still
> struggling.
Staying on-list is always preferred.
>> How is the index sl_city_etc defined?
>
> Index "public.sl_city_etc"
> Column | Type
> --+--
On Thu, Jul 9, 2009 at 10:35 PM, Alex wrote:
> Forgot to add:
>
> postg...@ec2-75-101-128-4:~$ psql --version
> psql (PostgreSQL) 8.3.5
How is the index sl_city_etc defined?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.or
Forgot to add:
postg...@ec2-75-101-128-4:~$ psql --version
psql (PostgreSQL) 8.3.5
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Pierre-Frédéric Caillaud wrote:
Your suffering comes from the "where ba.bankaccountID =
u.bankaccountID" in the subselect. It means postgres has to run the
subselect once for each row in Users. You want the subselect to run
only once, and return one (or more?) bankaccountid's, then fetch
Your suffering comes from the "where ba.bankaccountID = u.bankaccountID"
in the subselect. It means postgres has to run the subselect once for each
row in Users. You want the subselect to run only once, and return one (or
more?) bankaccountid's, then fetch the users from Users.
Just
Pierre-Frédéric Caillaud wrote:
Just One, user can i have only one bankaccount.
Ah well, in that case :
This is your query :
select userID, fname, lname, email, phone, dateEntered, dateCanceled,
dateSuspended, billAmount, billDate, dateBilled, datePaid, '?' as
searches
from Users u
where
Just One, user can i have only one bankaccount.
Ah well, in that case :
This is your query :
select userID, fname, lname, email, phone, dateEntered, dateCanceled,
dateSuspended, billAmount, billDate, dateBilled, datePaid, '?' as searches
from Users u
where 1=1 AND exists (select userID
Pierre-Frédéric Caillaud wrote:
Just wanted to know the selectivity of the accountnumber and
routingNumber columns.
I shoulda written :
How many rows do the following queries return :
One or few at most, or a lot ?
Just One, user can i have only one bankaccount.
select userI
Just wanted to know the selectivity of the accountnumber and
routingNumber columns.
I shoulda written :
How many rows do the following queries return :
One or few at most, or a lot ?
select userID
from bankaccount
WHERE accountnumber = '12345678'
select userID
Pierre-Frédéric Caillaud wrote:
How many rows do the following queries return :
select userID
from bankaccount ba
where ba.bankaccountID = u.bankaccountID
and ba.accountnumber = '12345678'
select userID
from bankaccount ba
where ba.ba
How many rows do the following queries return :
select userID
from bankaccount ba
where ba.bankaccountID = u.bankaccountID
and ba.accountnumber = '12345678'
select userID
from bankaccount ba
where ba.bankaccountID = u.bankaccountID
22 matches
Mail list logo
