On Tue, Jun 21, 2005 at 09:46:50 +1000,
John Hansen [EMAIL PROTECTED] wrote:
Someone Wrote:
Should not check constraint act as the first filter? The index should
ideally be scanned only when the check constraint is passed by the
search
criteria but surprisingly it did not happen. The
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote
I think the real problem is that check constraints on tables
aren't used by the optimizer. Given that, what you have below
is expected.
There has been talk about that in the past, but I haven't
heard anything recently about someone
On Tue, Jun 21, 2005 at 21:54:34 +1000,
John Hansen [EMAIL PROTECTED] wrote:
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote
I think the real problem is that check constraints on tables
aren't used by the optimizer. Given that, what you have below
is expected.
There has been talk
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote:
You only want to use partial indexes when they don't cover
the whole table. They make sense to enforce uniqueness of a
column under some condition and when you can save significant
space (becuase the condition is only satisfied for a small
On Tue, Jun 21, 2005 at 22:11:25 +1000,
John Hansen [EMAIL PROTECTED] wrote:
I misunderstood the original post as a request for queries NOT to use
indexes where it doesn't match the table contents.
I think that is what they were asking, but I don't think they wanted
to see a sequential scan
Hi
I have createda base table with a column id of type int. This table is inherited by a few subtables each of which have rows which satisfy a range of ids. The ranges are mutually exclusive. For example:
0=id1 subtable1
1=id2 subtable2
2=id3 subtable3
3=id4
Rohit,
Now, when I do a select on the basetable with a range of ids, it looks up
each subtable that inherits from the base table and using an indexed scan
searches for values in the range. It does it even for subtables whose check
constraint completely rules out the possibility of it
On Mon, Jun 20, 2005 at 10:35:24AM -0700, Josh Berkus wrote:
Rohit,
Now, when I do a select on the basetable with a range of ids, it looks up
each subtable that inherits from the base table and using an indexed scan
searches for values in the range. It does it even for subtables whose
On Mon, 2005-06-20 at 14:40 -0400, Alvaro Herrera wrote:
On Mon, Jun 20, 2005 at 10:35:24AM -0700, Josh Berkus wrote:
Rohit,
Now, when I do a select on the basetable with a range of ids, it looks up
each subtable that inherits from the base table and using an indexed scan
searches
Someone Wrote:
Should not check constraint act as the first filter? The index should
ideally be scanned only when the check constraint is passed by the
search
criteria but surprisingly it did not happen. The explain analyze
showed
cost for index scans of subtables that cannot contain rows
This is called range partitioning. We're working on it. You're welcome to
join the Bizgres project where most of the discussion on this feature takes
place:
www.bizgres.org
http://pgfoundry.org/mail/?group_id=1000107
I still think the fact that that discussion is taking place on a
KL-
I still think the fact that that discussion is taking place on a
completely non-hackers mailing list is the lamest thing ever...
What, like phpPgAdmin? ;-)
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP
On Mon, 20 Jun 2005, Josh Berkus wrote:
KL-
I still think the fact that that discussion is taking place on a
completely non-hackers mailing list is the lamest thing ever...
What, like phpPgAdmin? ;-)
What on earth does phpPgAdmin have to do with the backend?
I'm on the list and
I still think the fact that that discussion is taking place on a
completely non-hackers mailing list is the lamest thing ever...
What, like phpPgAdmin? ;-)
Erm. Last time I checked phpPgAdmin was a userland application, using
PHP and libpq. Bizgres is proposing modifying PostgreSQL
Josh Berkus said:
KL-
I still think the fact that that discussion is taking place on a
completely non-hackers mailing list is the lamest thing ever...
What, like phpPgAdmin? ;-)
Josh,
That is not an appropriate analogy at all - range partitioning is an
inherently server-side feature,
Doh, sorry for coming off sounding like a knob here...my point is that
it's not like you guys are some sort of rogue faction implementing range
partitioning against the wishes of the Man - it's something that I
think we all agree we want in the backend, so I don't see why you are
making it
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
This is called range partitioning. We're working on it. You're welcome
to
join the Bizgres project where most of the discussion on this feature takes
place:
www.bizgres.org
http://pgfoundry.org/mail/?group_id=1000107
I still think the
Folks,
Any discussions at the level of changing infomask bits definitely belong
on -hackers. Do not be too surprised if you get an unfriendly reception
when you post low-level changes to -patches that were never previously
discussed on -hackers ...
Oh, I'm not expecting this to make it into
18 matches
Mail list logo
