just wondering if there's a special tweak i can do to force more usage
of indexes to do BITMAP ands?
I have a table like
A int
B int
C int
D int
E int
F int
g int
where A/B/C/D/E are indexes
There's ~20millions rows in the table.
Query are something like this.
select * from table
where A=X
a
"Matt Klinker" <[EMAIL PROTECTED]> writes:
> Sorry for not including this extra bit originally. Below is the explain
> detail from both the query to the view that takes longer and then the query
> directly to the single table that performs quickly.
...
> -> Subquery Scan *SELECT* 1 (cost
Sorry for not including this extra bit originally. Below is the explain
detail from both the query to the view that takes longer and then the query
directly to the single table that performs quickly.
Hash Join (cost=49082.96..1940745.80 rows=11412 width=76)
Hash Cond: (outer.?column1? = inner.
"Matt Klinker" <[EMAIL PROTECTED]> writes:
> I know it's generally requested to include the EXPLAIN text when submitting
> a specific question, but I thought perhaps this was generic enough that
> someone might at least have some suggestions.
You're usually only going to get generic suggestions fr
I'm trying to fine tune this query to return in a reasonable amount of time
and am having difficulties getting the query to run the way I'd like. I
have a couple of semi-related entities that are stored in individual tables,
say, A and B. There is then a view created that pulls together the commo
Scott Marlowe wrote:
On Thu, Apr 3, 2008 at 4:10 AM, sathiya psql <[EMAIL PROTECTED]> wrote:
There is NO MAX
It is according to your hardware you have, and the db you have.
Not entirely true. on 32 bit OS / software, the limit is just under 2
Gig. I'd imagine that the limit on
Andrej Ricnik-Bay wrote:
> On 04/04/2008, Scott Marlowe <[EMAIL PROTECTED]> wrote:
>> Not entirely true. on 32 bit OS / software, the limit is just under 2
>> Gig.
That depends on the OS. On Linux it's AFAIK closer to 3GB because of
less address space being consumed by the kernel, though I think
On Thu, Apr 3, 2008 at 11:16 AM, Andrej Ricnik-Bay
<[EMAIL PROTECTED]> wrote:
> On 04/04/2008, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> > Not entirely true. on 32 bit OS / software, the limit is just under 2
> > Gig.
>
> Where do you get that figure from?
>
> There's an architectural (theor
On Fri, 4 Apr 2008, Andrej Ricnik-Bay wrote:
On 04/04/2008, Scott Marlowe <[EMAIL PROTECTED]> wrote:
Not entirely true. on 32 bit OS / software, the limit is just under 2
Gig.
Or are you talking about some Postgres limitation?
Since the original question was:
What can be set as max of ¿½
On 04/04/2008, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> Not entirely true. on 32 bit OS / software, the limit is just under 2
> Gig.
Where do you get that figure from?
There's an architectural (theoretical) limitation of RAM at 4GB,
but with the PAE (that pretty much any CPU since the Pentium
On Thu, Apr 3, 2008 at 4:10 AM, sathiya psql <[EMAIL PROTECTED]> wrote:
> There is NO MAX
>
> It is according to your hardware you have, and the db you have.
Not entirely true. on 32 bit OS / software, the limit is just under 2
Gig. I'd imagine that the limit on 64 bit hardware / software is
I think James was talking about Sybase. Postgresql on the other hand has a
slightly better way to do this.
SELECT ... FOR UPDATE allows you to lock a given row (based on the SELECT
... WHERE clause) and update it... without worrying about a concurrent
modification. Of course, if the SELECT ... WHE
There is NO MAX
It is according to your hardware you have, and the db you have.
2008/4/3 bitaoxiao <[EMAIL PROTECTED]>:
>
> What can be set as max of postgreSQL shared_buffers and work_mem
>
> 2008-04-03
> --
> bitaoxiao
>
>
> I find myself having to do this in Sybase, but it sucks because there's
> a race - if there's no row updated then there's no lock and you race
> another thread doing the same thing. So you grab a row lock on a
> sacrificial row used as a mutex, or just a table lock. Or you just
> accept that some
14 matches
Mail list logo
