2008/2/27, Scott Marlowe <[EMAIL PROTECTED]>:
> On Tue, Feb 26, 2008 at 10:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Markus Bertheau" <[EMAIL PROTECTED]> writes:
> > > 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
> >
> > >> No, what makes you think that? The index won't change at all in the
Tom Lane wrote:
Hardly --- how's that going to pass a notify name? Also, a lot of
people want some payload data in a notify, not just a condition name;
any reimplementation that doesn't address that desire probably won't
get accepted.
Ah - forgot about the name. At least there need be just o
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> On the other hand, if the only reason to have that feature is to plan
> and execute queries pretending that one index doesn't exist, then DROP
> INDEX DEFERRED is not the most straightforward syntax.
Yeah, I was just about to mention that 8.3 has a h
On Tue, Feb 26, 2008 at 10:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Markus Bertheau" <[EMAIL PROTECTED]> writes:
> > 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
>
> >> No, what makes you think that? The index won't change at all in the
> >> above example. The major problem is, as Scott says,
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
>> No, what makes you think that? The index won't change at all in the
>> above example. The major problem is, as Scott says, that DROP INDEX
>> takes exclusive lock on the table so any other sessions will be
On Tue, Feb 26, 2008 at 8:48 PM, Markus Bertheau
<[EMAIL PROTECTED]> wrote:
> 2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
>
>
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> >
> > >> begin;
> > >> drop index abc_dx;
> > >> select
> >
2008/2/27, Tom Lane <[EMAIL PROTECTED]>:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>
> >> begin;
> >> drop index abc_dx;
> >> select
> >> rollback;
> >>
> >> and viola, your index is still there. note that there are likely some
> >>
James Mansion <[EMAIL PROTECTED]> writes:
> I certainly hadn't expected that to be the implementation technique -
> isn't it smply that we need
> a sngle flag per worker process and can set/test-and-clear with atomic
> operations and then a
> signal to wake them up?
Hardly --- how's that going t
Joel Stevenson <[EMAIL PROTECTED]> writes:
> What's really baffling is that there are plenty of other OLTP queries
> going in multiple backends simultaneously that don't fall over my
> 300ms query log threshold, and yet NOTIFY and LISTEN consistently do.
> What's more it's looks like it's only h
Tom Lane wrote:
read-modify-write type of operation it uses an exclusive lock, so only
one can clear its pg_listener entry at a time. The 'waiting' ones you
are seeing are stacked up behind whichever one has the lock at the
moment. They shouldn't be waiting for long.
I certainly hadn't expec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 17:22:40 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> >> begin;
> >> drop index abc_dx;
> >> select
> >> rollback;
> >>
> >> and vi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>> begin;
>> drop index abc_dx;
>> select
>> rollback;
>>
>> and viola, your index is still there. note that there are likely some
>> locking issues with this, so be careful with it in production. But
At 12:43 PM -0500 2/26/08, Tom Lane wrote:
I'm still baffled by why we aren't seeing comparable performance for the
same test case. What I'm testing on is couple-year-old desktop kit
(dual 2.8GHz Xeon, consumer-grade disk drive) --- I had assumed your
server would be at least as fast as that, bu
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Tue, Feb 26, 2008 at 11:12 AM, Laurent Raufaste <[EMAIL PROTECTED]> wrote:
>> I tried increasing the stats target with the command:
>> SET default_statistics_target=1000 ;
>> That's the command I launched before executing the ANALYZE showed in
>> the
"Laurent Raufaste" <[EMAIL PROTECTED]> writes:
> 2008/2/26, Tom Lane <[EMAIL PROTECTED]>:
>> ... I'm wondering if you have a definition of operator <@
>> that doesn't specify the new selectivity estimator. Please try a
>> pg_dump -s and see what it shows as the definition of <@.
> Here's the firs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2008 14:57:51 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> The brick to the head method would use set enable_indexscan = off;
> However, you can delete an index without actually deleting it like so:
>
> begin;
> drop index abc_
On Tue, Feb 26, 2008 at 2:46 PM, Peter Koczan <[EMAIL PROTECTED]> wrote:
> This might be a weird question...is there any way to disable a
> particular index without dropping it?
>
> There are a few queries I run where I'd like to test out the effects
> of having (and not having) different indexe
This might be a weird question...is there any way to disable a
particular index without dropping it?
There are a few queries I run where I'd like to test out the effects
of having (and not having) different indexes on particular query plans
and performance. I'd really prefer not to have to drop an
On Tue, Feb 26, 2008 at 11:12 AM, Laurent Raufaste <[EMAIL PROTECTED]> wrote:
> 2008/2/26, Tom Lane <[EMAIL PROTECTED]>:
>
> >
> > What PG version is this?
> >
> > If it's 8.2 or later then increasing the stats target for _comment.path
> > to 100 or more would likely help.
> >
>
> I'm using
2008/2/26, Tom Lane <[EMAIL PROTECTED]>:
> "Laurent Raufaste" <[EMAIL PROTECTED]> writes:
>
> > 2008/2/26, Tom Lane <[EMAIL PROTECTED]>:
>
> >> If it's 8.2 or later then increasing the stats target for _comment.path
> >> to 100 or more would likely help.
>
> > I'm using PG 8.2.4.
> > We are usin
"Laurent Raufaste" <[EMAIL PROTECTED]> writes:
> 2008/2/26, Tom Lane <[EMAIL PROTECTED]>:
>> If it's 8.2 or later then increasing the stats target for _comment.path
>> to 100 or more would likely help.
> I'm using PG 8.2.4.
> We are using 100 as default_statistics_target by default and all our
> c
Joel Stevenson <[EMAIL PROTECTED]> writes:
> Now that I see a little bit more of what goes on under the hood of
> this function I see that it's still basically table-driven and I'll
> adjust my expectations accordingly,
Yeah, there's been discussion of replacing the implementation with some
all-
2008/2/26, Tom Lane <[EMAIL PROTECTED]>:
>
> What PG version is this?
>
> If it's 8.2 or later then increasing the stats target for _comment.path
> to 100 or more would likely help.
>
I'm using PG 8.2.4.
We are using 100 as default_statistics_target by default and all our
column are using this v
On Mon, Feb 25, 2008 at 11:56 AM, Matthew <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008, Kynn Jones wrote:
> > This is just GREAT!!! It fits the problem to a tee.
>
> It makes the queries quick then?
It is good that you ask. Clearly you know the story: a brilliant-sounding
optimization that
"Laurent Raufaste" <[EMAIL PROTECTED]> writes:
> I'm having some issues with this simple query:
> SELECT
> _comment.*,
> _article.title AS article_title,
> _article.reference AS article_reference
> FROM
> _comment
> INNER JOIN _article
> ON _article.id = _comment.parent_id
> WHERE
>
At 11:58 PM -0500 2/23/08, Tom Lane wrote:
> Attached is a perl script that sort of simulates what's going on.
Thanks for the script. It's not showing any particular problems here,
though. With log_min_duration_statement = 10, the only statements that
(slightly) exceed 10ms are the select cou
2008/2/26, Laurent Raufaste <[EMAIL PROTECTED]>:
> Hi,
>
> I'm having some issues with this simple query:
>
> SELECT
> _comment.*,
> _article.title AS article_title,
> _article.reference AS article_reference
> FROM
> _comment
> INNER JOIN _article
> ON _article.id = _comment.parent
Hi,
I'm having some issues with this simple query:
SELECT
_comment.*,
_article.title AS article_title,
_article.reference AS article_reference
FROM
_comment
INNER JOIN _article
ON _article.id = _comment.parent_id
WHERE
_comment.path <@ '0.1.3557034'
ORDER BY
_comment.date_publis
Do not use setString() method to pass the parameter to the
PreparedStatement in JDBC. Construct an SQL query string as you write
it here and query the database with this new SQL string. This will
make the planner to recreate a plan every time for every new SQL
string per session (that is not usuall
Hi,
You may remember some thread about data loading performances and
multi-threading support in pgloader:
http://archives.postgresql.org/pgsql-performance/2008-02/msg00081.php
The pgloader code to handle this is now ready to get tested, a more structured
project could talk about a Release Can
30 matches
Mail list logo
